DSP Robotics Support

tulamide wrote:That's what I was hoping for. Someone who understands the impact of it and is willing to take over the DSP coding! Thank you so much.

You're welcome. I hadn't realised until I saw your thread that the 'sequencing' code might have other uses. The only problem I can foresee is much as Spogg mentioned earlier - for quick response to note-release, you'd ideally need to skip forward to the release portion of the envelope-points sequence. That would need to be smoothed or have levels 'normalised' somehow, because you'd effectively be joining two splines where there's no shared control node. Even if I can't resolve that straight away, I'll get something sketched out as soon as I can, so that I can at least give you an exact spec' for the array of data that your spline editor will need to pass to the DSP.

Spogg wrote:I’ve given some thought to wavetable sequencing myself... ...But I couldn’t think of a way of doing it smoothly using the prims we have available...

Well, you can give yourself a few brownie points for inspiring me to take a look into it! And it's very apt that you should mention Kevin, too. It was in his synths that I first came across your morphing oscillator, which led me to have a "why did I never think of that?" moment when I saw how you use a mem array to store whole wavetables rather than just individual wave cycles. Like all of the greatest ideas, it seems obvious as soon as you've seen someone else do it first!

Then, as you suggest, I realised the limitation that using the stock wavetable oscillator forces you to use the 'Mem Array Get', which only has a 'green' index selector, so you can't switch wavetables at sample rate. I worried that the algorithm to play back the right single cycle from a wavetable might be a bit of a nightmare to reverse-engineer, but it turned out to have a very simple and elegant solution. You can see from the mem size that the number of entries in a wavetable is sample_length/2, and the one to play is just 1.0/normalised_frequency (up to the limit of the number of table entries).

Besides wave-sequencing, the wavetable-array reader would allow your morphing oscillators to have their shape modulated at sample rate (there's a rough sketch of that in the 'scratchpad' module of the schematic). Hence, I've kept the reader module separate from the sequencing code, as it struck me as being a component that others might come up with some interesting uses for. Once I've ironed out a couple of remaining glitches, I'll convert the DSP code to ASM (there are a lot of potential CPU savings), and then I'll upload them as a little 'wavetable toolkit' (and stop spamming tulamide's splines thread with all this talk about wavetables - sorry!)

OK, here's a first stab at the DSP code for the envelope generator...
EDIT: Download removed. A newer version is now available later in the thread

As you'll be making a full-featured GUI using the splines, I've only included a very basic node editor, but the DSP code doesn't care which nodes are control nodes and which are mid-spline segment nodes, so it should be easy to adapt. There's a comment box with full details of the Array format for control data - it's very simple, just a four-value header for 'global' settings, followed by a list of alternating envelope levels and node-to-node transition times. There are couple of limitations:
- It can only handle one node-to-node transition per sample, so might glitch if nodes are less than one sample apart in time.
- The two ends of the sustain loop must have the same level to avoid a step when it wraps around.

I've included what I think is a reasonable solution to the note-release problem. When the note is released, the envelope jumps immediately to the end of the sustain loop, and all of the following nodes get scaled so that the release phase begins at whatever the current envelope output level is. It could also be made so that all segments always play through regardless of when the note is released, which I could probably make a selectable option if you think that might be useful for some patches (drones or 'trance-gates' maybe?). Like the stock envelopes, it can be controlled either by the automatic system of the MIDI-to-poly or by using an explicit gate link.

I would guess that there are still a few bugs in there to iron out, and the VST preset system probably needs changing (better to save your spline control handles than the array of segments, I would think), so give it a spin and let me know if there's anything which doesn't work as you expect it to.

OMG, that was quick! I'm not nearly as quick, so I hope you are fine with some patience.

I have to re-write some portion of the code to not put the best quality in the array (it was designed so that even when drawing is restricted to, say, 2 segments, the actual spline values would be calculated from the invisible highest quality spline, in order to save cpu on drawing while still having the finest curvature in the data)

As soon as I have it changed to wysiwyg, I will try it and report back!

That’s already a brilliant envelope generator trog.

I know the editor is “only” for testing, but it’s great!
I had just one issue with it. If I double click in the space beyond the final node I get a Ruby error and have to reset the RubyEdit.

You amaze me trog, always.

Cheers

Spogg

tulamide wrote:OMG, that was quick! I'm not nearly as quick, so I hope you are fine with some patience.

No problem, take as long as you need. It was just easier for me to do it straight away while the code was fresh in my mind, and aside from getting the release part working, it was more a matter of deleting code that wasn't needed rather than writing much that was new.

Spogg wrote:If I double click in the space beyond the final node I get a Ruby error and have to reset the RubyEdit.

That was actually a "feature" (sort of!). While I was editing, I found that I could lock-up the DSP code if I added a point at the end while a note was running, so to ease debugging, I let the Ruby crash instead! Thanks for the heads up, as I'll have to check whether the DSP code now handles that situation a bit more elegantly.

Incidentally, I realised overnight that by removing the envelope-stage code and having a node array which is "all loop", it would also handle your "spline LFO" idea, too. I'll leave off doing that for the moment, just in case tulamide discovers anything that needs tweaking to fit his spline implementation, but the same interface for custom LFOs and envelopes would be rather nice, I think.

Here's an update to the DSP code with an important fix and a few other goodies.

EDIT: Download removed: Click here for the latest version.

Fixes
- Automatic envelope stages now work properly. The old version wouldn't retrigger if there was another envelope in the schematic with a longer release time (many thanks to Spogg for his detective work on envelope "stage 5" a while ago, that was just what I needed to know to find the bug).

- Fixed the Ruby bug that Spogg mentioned earlier. It turned out that the earlier DSP lockups were when the loop end was put before the loop start due to a related bug in the editor. I've added basic loop-point editing/deleting to the temporary GUI so that it's easier to experiment without breaking it!

New Feature

The previously spare slot in the header metadata now stores a loop "mode" parameter (the rest of the data structure is unchanged). There are four modes available...

0) Single-Shot: The whole envelope curve plays through for every note-on without any looping. Good for e.g. drum sounds. The same happens if the loop points are removed (done by pointing them past the end of the sequence).

1) Quick-Release: The mode used in the previous version; with sustain looping, and jumping straight to the release segments at note-off, with release segment scaling to smooth the join. Closest to a typical synth envelope.

2) Phrase-Release. At note-off, playback continues from the current position and only escapes from the loop when it reaches the end of the current cycle, and release segments are not modified. Should suit e.g. tempo-synced pitch modulation, where the Quick-Release mode could throw out the sync or pitch depending on the timing of note-offs.

3) LFO: In this mode, release segments aren't used. Instead, the sustain loop carries on looping even after note-off. Effectively, the loop becomes a single-cycle of an LFO. Pre-loop segments can still be used, maybe to define a fade-in for the modulation or to emphasise it at note-ons. Since the looping has no natural end, the module doesn't keep voices 'alive' after note-off when in this mode, so there must be at least one other envelope in the schematic to determine a release time.

A selector for the modes is now present in the test editor, and it also has a property to select uni-polar or bi-polar values to best suit the modulation destination. In principle, a synth could have several of these modules as generic "modulators" and leave it up to the user to decide which to use as envelopes and which as LFOs by selecting the loop mode (whether that's actually a good idea from a GUI/ergonomic point of view, I'm not quite so sure!)

That’s fabulous trog!

It seems to do everything I would want and I couldn’t break it.

One very minor thing I would personally prefer, but it’s a matter of taste and opinion, is to use right-click to delete a node and left-click to add one.
I say this because it’s what I got used to when I was using Martin’s curve drawing code, and it’s certainly not very important.

Cheers

Spogg

Just downloading, so haven't used it yet, but from Rex' praise it seems the work is already done? No spline programming needed anymore?

tulamide wrote:No spline programming needed anymore?

Far from it - the splines are exactly what it needs, IMHO. Using splines rather than the current linear segments would make editing a great deal easier, I think. At the moment, to make a "curve", you manually have to create a bunch of intermediate segments. If you then want to change the curve's slope or length, you have to adjust every single intermediate node for every change. With splines, you could potentially drag just a single control handle and get the job done with a fraction of the effort, even for a really long curve that's not all visible in the editor at once. It would also have some technical benefits, such as making VST presets smaller, as you'd only need to store control handle positions, not the positions of every single intermediate segment.

If folks are happy giving themselves RSI from moving dozens of points around every time they want to change the length of an envelope phase, then the temporary editor might do at a pinch; but once they see it done with splines, they won't want to go back to doing it my way, I'm sure! So don't lose heart - if other people can't imagine it yet, it will be all the more of a pleasant surprise to them when they discover how much more user-friendly it is!

PS: I should have a simple Ruby module ready for you shortly that will act as an API for packing, unpacking and validating the DSP data. I've realised that, once converted to ASM, there may be significant CPU-load benefits from packing the data differently or using a Frame to pass it instead of a mem. The Ruby module would act as a consistent interface, so that the editor code won't need to change every time I change the stream implementation - you'd just 'include' or 'extend' the latest version of the API module.

Spogg wrote:One very minor thing I would personally prefer, but it’s a matter of taste and opinion...

It is a PITA switching between apps that use different mouse/key combinations, that's for sure! Whenever I'm editing Ruby in an FS RubyEdit, I'm constantly frustrated by my Notepad++ code-editor keyboard shortcuts not working!

It is something I've been giving a bit of thought to lately (the wave-sequence editor I posted is even trickier - there's barely a click/modifier-key combo that isn't used). With Ruby, it would be relatively easy to assign 'action' routines to particular combos, so that they could be user-configurable to match each user's muscle-memories (in fact, that's how most OO-language "GUI frameworks" do it, as it has many benefits for the coder, too).

trogluddite wrote:

tulamide wrote:No spline programming needed anymore?

Far from it - the splines are exactly what it needs, IMHO. Using splines rather than the current linear segments would make editing a great deal easier, I think. At the moment, to make a "curve", you manually have to create a bunch of intermediate segments. If you then want to change the curve's slope or length, you have to adjust every single intermediate node for every change. With splines, you could potentially drag just a single control handle and get the job done with a fraction of the effort, even for a really long curve that's not all visible in the editor at once. It would also have some technical benefits, such as making VST presets smaller, as you'd only need to store control handle positions, not the positions of every single intermediate segment.

If folks are happy giving themselves RSI from moving dozens of points around every time they want to change the length of an envelope phase, then the temporary editor might do at a pinch; but once they see it done with splines, they won't want to go back to doing it my way, I'm sure! So don't lose heart - if other people can't imagine it yet, it will be all the more of a pleasant surprise to them when they discover how much more user-friendly it is!

PS: I should have a simple Ruby module ready for you shortly that will act as an API for packing, unpacking and validating the DSP data. I've realised that, once converted to ASM, there may be significant CPU-load benefits from packing the data differently or using a Frame to pass it instead of a mem. The Ruby module would act as a consistent interface, so that the editor code won't need to change every time I change the stream implementation - you'd just 'include' or 'extend' the latest version of the API module.

Thanks a lot! I needed this encouragement, because for a minute I really thought my work isn't needed anymore. And you're right, the spline implementation is so much more convenient, and will be accepted once they see it!

Your ps blows me away. I would never have hoped for so much comfort! Now I can concentrate on the Spline editor alone, which helps me a lot regarding my personal issues that break ground when my mental stress level gets too high. Wow, for the first time in so many years on this forum, I have the feeling that somebody understands my vision and helps me actively with collaborating.