Sugestions, wish lists, etc...

[eXode]

I don't know if this have been suggested but I'd like to suggest different function modules such as sample and hold, slew limiter, clock divider, logic device, trigger delay etc. I personally think such features are more interesting than effects. Also I don't know if theres noise in there already but white and pink noise (at least) should also be there! :)

[sonigen]

sample and hold, slew limiter, clock divider, logic device, trigger delay etc. I personally think such features are more interesting than effects.

I've added them to the list of ideas to look into. That said i'm not trying to recreate an analog modular in software. So if there's a better way to achieve the same results I'll try and find it.

For example 9 times out of 10 it seems people use a S&H module to turn a noise source (or some fairly random source) into a random step function. But it's simpler and more useful to implement that as a wave shape for the LFO, (in my opinion anyway)

Also I don't know if theres noise in there already but white and pink noise (at least) should also be there!

There's a noise module with variable colour and crackle. It wont give you pink noise exactly but it gives you a pretty varied pallet to choose from.

[eXode]

Yes, s&h random is a features that could be easily mimicked with a LFO and a random function. If going that route though I'd suggest for atleast some sort of slew so that one can gradually change from "steppy" to "smeary" :) could be fun to be able to play with the for the other waveshapes as well (atleast square and saw), esp at higher rates.

Thanks for claryfing about the noise module!

This is also just a suggestion but have you thought about mimicking some of the more exotic modules from buchla and serge? Like the Source of Uncertainty or Smooth/Stepped Generator and stuff like wavefolders etc and other exotic function units. I think genereally that this is an area of ground that is not much covered in software synthesis. :)

[Jesse J]

Yes, s&h random is a features that could be easily mimicked with a LFO and a random function. If going that route though I'd suggest for atleast some sort of slew so that one can gradually change from "steppy" to "smeary"

I agree, but you CAN smooth out control signals by sending them trough a LP filter. A dedicated slew would be handy thou.

[sonigen]

If going that route though I'd suggest for atleast some sort of slew so that one can gradually change from "steppy" to "smeary"

Actually the LFO did have an adjustable lowpass filter at one point but I removed it because it started to get a bit expensive when pitch mod was involved. Having the LPF track pitch modulation cost almost as much as the whole LFO on it's own. But I could add it in where it doesn't track the pitch mod, or maybe make it optional I guess.

Anyway it's added to the ideas list.

This is also just a suggestion but have you thought about mimicking some of the more exotic modules from buchla and serge? Like the Source of Uncertainty or Smooth/Stepped Generator and stuff like wavefolders etc and other exotic function units. I think genereally that this is an area of ground that is not much covered in software synthesis.

I'll have a look into it. I have got "chaotic LFOs" on the list already but so far the idea is basically to have noise go through a bandpass filter, so you get a periodic but wobbly sort of LFO. So some of those ideas might fit in with that.

[sonigen]

I agree, but you CAN smooth out control signals by sending them trough a LP filter. A dedicated slew would be handy thou.

I have a "portamento" module on the list so I could probably work slew rate limiting in with that.

I actually have a non resonant 1 and 2 pole LP/HP on the list too, mainly because a simple module like that wont use as much cpu as the MultiFilter.

[kvr797]

First: Congratulations on an amazing job so far! I'm very impressed

Tiny Suggestion: Dragging cables
Having played with it for a week+, I think the 'patching' could still be improved a bit. The way it works now - with the menu - is very clear, but with the cables in the interface, I think a mouse based dragging cables would be a very intuitive addition. (Shift+left click, for example - prevents mistakes)


I'm looking forward to hear your view on this.

[sonigen]

I think a mouse based dragging cables would be a very intuitive addition. (Shift+left click, for example - prevents mistakes)

I'm looking forward to hear your view on this.

It is possible in the future. I am very keen to make things as fast and intuitive as I can, that's one of the main goals of the whole design. But drag and drop cabling is low priority right now.

There is however one issue that concerns me about that approach. It's how do you determine what target the dragged cable should go to? For example, if you drag an output to the Multifilter it could be for the audio in, cuttoff mod, or resonance mod.

ATM i see only two solutions, either have extra icons for each input onto which you drop the dragged cable. I don't like this solution as it adds extra noise to the GUI. Or you pop up a little menu that asks what input to put it to, which is half way the existing solution and kind of defeats the purpose.

Thanks,

Chris

[Jesse J]

it adds extra noise to the GUI.

I'm with Chris on this one. My initial reaction was also for drag-drop cables, but after using Sonigen Modular for a while I actually now prefer it as it is, the GUI is sleek and uncluttered this way. I specially like the fact that the user can rearrange the position of the patchpoints and that there's the automatically added attenuator pot, it's just great for workflow.

Looking forward for next release!

[jupiter8]

I'm really curious about the JIT Assembly. That's like the geekiest thing i've ever heard and i heard a lot. What was the thinking there ? Did you do it all by yourself or did you you use a library or something ?

[sonigen]

I'm really curious about the JIT Assembly. That's like the geekiest thing i've ever heard and i heard a lot. What was the thinking there ? Did you do it all by yourself or did you you use a library or something ?

The thinking was....

1. A Modular must have per sample processing, not block processing.
2. The modules must be able to handle a dynamic number of inputs.
3. How do I overcome the per sample overhead of calling each module?
4. How do I overcome the loop overhead for the dynamic input handling?

For example the MultiFilter has 3 inputs so you have the function call epilog and prolog, the actual indirect call overhead (and a vtable lookup), and you have arrays of inputs which need to be iterated and accumulated, and those parameters need to be passed in.

That could easily add an extra 50% cpu load on something like the MultiFilter, but on something like the LFO it could end up costing more than the actual LFO code does.

So I ended up tinkering with generating code at run time. To be honest it evolved over a couple of years and while the JIT design is quite clean and effective now, it was fugly to begin with.

But now everything is inlined, parameters stay in registers, loops unrolled, code is conditionally included or not, the stack is hardly ever used, very few branches are needed. Etc..