Is that because of bad presentation? (I was aiming for "breezy" rather than "plodding", which I fear is my default mode). But it might just be too rushed. Or is it just not your thing?

@@synaesmedia No, nothing wrong with the presentaion. Just that I'm understanding less and less these days.

Let's hope this gives me the momentum again.

Thanks. I believe there is a lot to explore here. But I need to get to the actual Volca Modular / VCase jamming / video soon. My hunch is that that's going to work better if I swap the Modulators for a filter. It's a shame to lose modulation, but the VM has its spare function generator, and if I do that, I can put the Kaestle Drums through the filter, while freeing the Cirrus for the VM itself. Anyway will see how that turns out and document it soon.

Thanks. I really like the rhythms that come out of playing with the Volca Drum. At the same time, I really need to sit down and learn some sound design on it. (It's a relatively new acquisition). Because these drum sounds are way too hard and bright for the vibe I was exploring. I need to figure out how to make the kick lower and mellower. And tone down the other instruments too. Also, listening to the video, the Kaestle / Cirrus needs to be louder in the mix. But it's an enjoyable combo to jam with.

@@synaesmediaI find it's quite hard to make the cirrus/kastle louder unless putting it through the 2Signalamp or quadboost. Would really like to play with the drum as I've heard complicated sounds and rhythms coming from it. Enjoy!

@@maydonpoliris Yeah . Kaestle Drum definitely feels quieter than my normal Bastl Kaestle. Don't know if that's the algorithm in the Drum, or the way the AE version is built. I hear other people making some beefier drums with it than I managed so far. So need to experiment more. Or it could be the Cirrus making everything quiet.

@@synaesmedia and every patch is different so we may never find out why but I guess that's the fun we have while experimenting 🙂

Thanks Yes. Sam has definitely given us something fantastic.

Hurts m my fingers too much. 😀 But I ought to try learning the keyboard properly.

That sounds pretty awesome. I have no idea how to persist values. I guess PD has the ability to write files. But is there a way to discover what the current setting of all the sliders is? Or do you have to explicitly set up routing their outputs to another recording component?

@@synaesmedia you got to build a circuit for it. You'll see you when I get my video together.

Indeed it was. I really need to make some more videos documenting where I'm at with this stuff. There have been developments. Some pretty crazy.

Thanks.

Hmmm ... I'll take a look at that. Maybe it's FL 21.1 or something that it became available. Are you on the latest FL?

@@synaesmedia v21.1.1 [build 3750] I stayed on this version because it flies faster and I am satisfied with its stability

you have to import/install the module pip install 'insert the module name '

Thanks. That main track 3 riff was made with a self-written Pure Data patch explored here : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ICw4gL2QKWg.html

1) The timing is "OK". It's obviously not like writing C where you are compiling to machine code and have to manage your own memory. It's a scripting language running on a virtual machine that does its own garbage collection. Which adds a certain overhead. And perhaps there are delays from the garbage collection. But it's fast enough to do some basic sound synthesis (which means running a loop to calculate audio samples 44,100 times a second. And I'd say it's probably OK for generating MIDI data in real time, if that's your main interest. If you want to generate a LOT of MIDI data it might choke. But computers are fast these days. ALSO, being a VST plugin, I *think* it gets its clock from the DAW. So keeping it in sync with the DAW should be OK. I've not tried anything like that, though. 2) The real issue with running a "sequencer" as a VST plugin, is that the VST standard doesn't, AFAICT, specify anything about routing MIDI. What that means is that in each DAW you'll have to figure out if and how you can do it. You'll see me explain this in the context of FL Studio at about 3 - 5 minutes into the video. It will probably be different in Ableton. I don't know if it's possible to send MIDI data out of the plugin on multiple MIDI channels and have them routed to different instruments within the DAW. But even if it is possible, what I'm certain of is that the plugin won't be able to set this up for the user. Every user is going to have to figure out how to configure that routing by themselves; before they can use the plugin. Which is a pain. In terms of robustness. It's probably robust enough that if you write code that doesn't crash, the plugin itself won't crash. 3) I've run 2 or 3 copies of Protoplug at once, and didn't seem to have any problems. I think the VST standard does encapsulate plugins OK. I'm not sure if there is a way multiple copies of the same VST leak into or interfere with each other. I'd guess not, normally. And haven't seen anything like that in Protoplug. 4) There are some calls in the API for saving and loading data. I guess to files somewhere. See www.osar.fr/protoplug/api/modules/script.html#saveData I've not experimented with this myself. VSTs obviously do save their state in some way when the track that holds them is saved. By default in Protoplug the current script is saved. If you wanted to save actual sequence data, my hunch is that it's probably possible, using the API. But I've not looked into it. In general, depending on what you are doing, Protoplug MIGHT be the solution for you. If it's some kind of algorithmic generation, and you are happy setting up MIDI routing yourself, then it might be a very good solution. OTOH, if you are trying to write an alternative sequencer and just want to use the DAW to host VST instruments, my hunch is that it's not necessarily right for you. One alternative is to run a program completely outside the DAW, and just send MIDI from it as though it were a MIDI controller. That's what I do from Gbloink! (See ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Q7PD00jvCy0.html and ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-PG3UhG_PWT8.html ) I found a Midi Mapper for Windows, and used it to route 3 channels of MIDI into FL Studio. I also route MIDI From Sonic Pi to FL Studio by the same mechanism. The irony with FL Studio, is that it seems easier to route multiple MIDI channels coming from *outside* the DAW, to different instruments, than it is to route multiple MIDI channels generated by a plugin *inside* the DAW. But Ableton might be different. Of course, an external program won't get a MIDI clock or be able to sync. Unless you use Ableton Link which I've not tried, but I believe Sonic Pi uses it and can sync to Ableton via it. A final option if you're not scared of C++ / JUCE is that I believe JUCE now supports JS scripts. So it might well be possible / or soon be possible, to write your own sequencer / DAW, largely in Javascript, sitting on a small core of JUCE C++. This is something I'm meaning to try out. Perhaps later this year, when I get some time. If I do, I'll certainly be making videos about it.

Thank you very much@@synaesmedia for such a lengthy response. I have subscribed to your channel. Please continue to make videos. You're great at explaining things. Please consider making a video about a simple midi sequencer. Thanks in adv.

It shouldn't be very hard. If you know how to install a VST plugin, you can install Protoplug. Get it : www.osar.fr/protoplug/ I have a series on using it here : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zkgYBoiQPek.html But basically you open it like any other VST, except there's a whole programming language environment inside it. My code for the long delay is here : gist.github.com/interstar/7cc4b8cb99dcd2bccffca21a4d2459ef So you can just copy and paste that into the Protoplug window and press compile. If you have the right version of FL Studio you have Patcher too. So you can assemble Protoplug within any larger patcher collection of plugins (eg. filters, reverbs etc) you like. The secret of the "Parallel delay" is just to make a second patcher, that has two copies of the first patcher in it, in parallel, and set them to different delay times, so they phase against each other. Or make something MORE complex if you want to hear how that turns out :-) Good luck. Have fun!

What would you like to see next, following on from this?

@@synaesmedia Yeah i suppose following on from this, or any other interesting decaying loops/ambient techniques you have picked up for FL studio.

@@zero111zero I don't know if you saw this recent video : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-PEUZZCpzkWo.html where I built a long parallel delay with a little bit of coding in Protoplug and Patcher. Now that there's a basic framework for building that delay fx in code, there's no reason we couldn't do more things to the sound in the buffer. For example, add some kind of custom noise or degradation to it. I'll play around and see if I can find some interesting algorithms that are fairly simple to implement but have useful / unusual effects.

You mean the glitch from tweaking the delay length? Which then gets captured and repeated? Yeah, that's interesting. In some ways it would be nice to eliminate it. But actually I don't know how. And even "professional" delays (at least the delay3 in FL Studio) have some amazing glitch effects when you mess with the delay while they are running. I think we have to assume that this is "character". And, yeah, can add some nice textures. As I deliberately do with the delay3 at about 30:00)

I've had a quick look on the images I have from my old BBC disks (I managed to rescue some files from them back in about 2012). But I'm afraid I can't see anything that looks like these example files. To be honest, as they are examples that came with the software, I probably would have deleted them at some point to make room on the disk for one of my own compositions. Disk space was always tight back then.

Thanks for trying!

@@virtuafighter3 No probs. Interesting to hear from anyone who remembers it. This was my first "DAW" back in the 1980s 🙂

He he ... thanks for noticing. (And sorry, I only just saw your response now. Been somewhat distracted from this channel recently). Yeah, that was a direction I was going in because I wanted a more sophisticated vocabulary for specifying the chord sequences. But after using it a bit I decided I really didn't like using the associative array notation. I found it verbose to write, and not easy to read. So I've pulled back from it. The more sensible way in Sonic Pi is to add custom :symbols. Just as Sonic Pi already does. It might be more of a faff to process and decode symbols, but I think using them will make the chord language much better. So that's on the todo list, and when I finish it, I'll definitely be making a new video on it.

Thanks. Have fun. BTW: I add some more chord types in the next videos in this series. And if you think of some others then I'll be interested to see them.

In principle you could make something that sounded like a trumpet or a guitar in this, yes. In practice, in electronic music, you are normally working at one of several levels. For example, if I'm writing a piece of music and I already know I want a trumpet or guitar, I'm more likely to just use a preset from one of the synths or samplers I already have. Most DAWs already have reasonable versions of these common instruments. Even in a free DAW like LMMS you have guitar and trumpet samples, or can use a VST plugin. If I was particularly interested in the *sound design* aspects of how to make trumpet or guitar sounds from scratch in a synthesizer, and I was using FL Studio, I'd probably start with the 3x Osc plugin. That's a simple 3 oscillator synthesizer which comes as standard with FL Studio. It looks pretty basic, but you can find people doing some phenomenal things with it (eg. www.image-line.com/fl-studio-news/3x-osc-shakuhachi/ ) So what about Protoplug? The main virtue of Protoplug is you can learn the next level down, how to actually program the underlying architecture of synthesizers in code. And armed with that knowledge you can make your own synthesizers. That's an interesting / fun activity, but you're mainly likely to do it as a learning exercise, or to make something more experimental, which works on principles different to any other plugin you have. You don't need to do it just to get the more common sounds or synth functionality. Could someone make a clone of 3x Osc in Protoplug? I think they probably could. It's a bigger project than any I've shown in my tutorials here. But it's probably not so much bigger. If you understood all the tutorials I've made about Protoplug, and are now reasonably confident programming in Lua, could probably build out from these examples to a 3 Oscillator monosynth, with sin, saw, square, noise waveforms, an amplitude envelope, filter envelope and LFOs, FM etc. Probably with a couple of weeks, if you're keen. And then you can do all the sound design you might do in 3x Osc, in your own synthesizer. 🙂 IN THEORY you could then go on to build even more powerful synthesizers. Ones with far more oscillators and modulation possibilities. Comparable with something like Sytrus or Serum etc. In PRACTICE, you have to remember that Lua is slower and less efficient than writing code in C++, and I suspect that if you tried to write a really big, complex and powerful synthesizer in Protoplug, your machine couldn't handle it. On the other hand, Protoplug uses the C++ JUCE framework behind the scenes, and so by the time you are thinking about designing and programming a big complex synth in Protoplug, you might well be ready to move on to just doing it in C++. Protoplug is a nice, intermediate step along the way to learning that, but eventually, if you are interested in writing the code behind synths, you will need to get to grips with doing it in C++. Hope this makes sense and helps.

Sure. Big Vince Clarke fan here. Also, feels a bit OMD-ish to me, too. Or at least how I think of OMD as sounding (can't say I know them that well, but there's a kind of grandiosity about them compared to some of the others. I see them as the ones most likely to go off on big dramatic choruses). Same to you on 2023.

The author occasionally pops up on the GitHub. I'm hoping if we get enough people using it, and talking about it and sharing new scripts etc. he'll feel re-enthused and come back.

Yeah. Until I was faffing with this I hadn't realised you could map each channel in the channel rack to a different MIDI channel. But it's essential. And great that FLdoes it.

Yep. There's a lot you can do with it. Some really weird specific echoes, or filters etc.

Thanks. Tell me if you want more Processing / MicroBit stuff. I've got a couple ideas in the pipeline.

@@synaesmedia Yes please!

That's a great idea. I need to try it. Perhaps running 3 or 4 waveshapers in parallel in Patcher and then blending between them.

you're right, it's not the same effect 😞😞😞

@@ramalshebl60 sadly IDK if there's a better way with stock effects :( I remember trying a free waveshaping VST called Drive (by Audec) that allows curve automation though. the curve is simpler, but maybe it'd be more interesting than just mixing parallel signals