DSP Robotics Support

It's taken rather longer than I was hoping, but here's a completely overhauled version of the basic "straight line" node envelope...

The example patches should show how versatile the underlying code is - it works equally well as an envelope, an LFO, or a step-sequencer, and various mutant offspring of those (a "Stenelleffope", maybe?). However, as the underlying DSP parameters are exposed pretty directly on the GUI at the moment, you may find that some settings don't do anything very useful, and there may still be a few combinations which go splat!

In deference to Spogg's earlier suggestion, there's now a modulation input for the playback speed (disabled when an envelope's speed is slaved to the 'Master' BPM). This works in powers of two, rather like note pitch; zero = no change, +1 = double speed, -1 = half speed, and so on (oh; and add/remove node is now on R-click!)

Besides reading the notes in the schematic, I strongly advise turning on the "Watch" button on the envelopes to begin with. Redrawing the GUI will consume more CPU (hence it's not turned on by default), but the animated playback cursor makes it a lot easier to see how the nodes, modes, and markers interact.

@tulamide
Most of the Ruby source code is tucked away inside the 'Master' module - the envelope modules have only bootstrapping code for pre-defined Classes and Modules. The API code and editor code are separate so that you can easily cut and paste only what you need. There's also a text box inside there with the documentation for the NodeEnvelope Ruby API.

There's still a fair bit of work left for me to do on this before it's "toolbox ready" - I'm starting work on converting the DSP code to ASM next. But the Ruby API should be definitive, regardless of what changes I make elsewhere; though I'm open to any suggestions that you have for improvements. Let me know if you need some simpler API working examples - the editor code probably has far too much other clutter inside it to make a good Ruby example.

Can't wait to see it!!!1!11

(I'm excited as a toddler having 4th birthday!)

OMG!

I’m really busy with other stuff at the moment so I only had a quick look, but this is amazing stuff trog. I’m really looking forward to the “toolbox-ready” version.

Cheers

Spogg

Wow trog,

This is really nice,like tulamide said, can not wait to see it completed.

Later then, BobF.....

Ok, so I'm still reading the ReadMe, trying to get comfortable with it. But there are a few questions, trog.

1) On the top level, I am extremely confused by the use of the word "node". On a basic spline, I have two nodes, at least two control points and cubic interpolation on the section between the two nodes, which creates segments (linear interpolation from one point to another, until section end (one of the nodes) is reached. Also, the order of the nodes doesn't matter, if I drag the left node way past the right node, the spline is still drawn perfectly fine (although it is now drawn from right to left)

From the description in the readme I understand that I have to give up on the latter property, because they must be in a time order? (To understand my question, imagine the spline's x-axis expressing time. The spline still shows a curve from left to right, but its internal values start at the right node moving towards the left one. It is possible for me to work around that by switching node drawing order [for a reason I cannot explain, it is already present in the code], but I need to know if or if not my assumption is right)
And your nodes are basically the segments in my spline, correct?

2) As complex cubic interpolation can't be reduced to a level/time pair, I can't use the translator directly. If I understood correctly. So, I would need to feed ::nodes with an array of level/time, precalculated similar to what I already do in my spline class (just switching x value with time value)?

I'm sure there will be more questions, but I keep them for later to lure you into thinking that you won't have much trouble with me

tulamide wrote:I'm sure there will be more questions, but I keep them for later to lure you into thinking that you won't have much trouble with me

Honestly, don't worry about it - I realised quite early on that the DSP code is a rather complex beast to drive, so I expected that anyone trying to make a GUI for it would probably need a bit of help along the way (it took me long enough to make my "primitive" editor!)

To briefly answer your questions here...

1) Yes, a "node" is just any arbitrary [x, y] point on your curves - aside from being scaled to time and modulation to account for grid-size/zooming. Apologies for the confusion - it's just because in my primitive "straight line" version, all of the points are control nodes! How or when the points are sorted into time order, it doesn't care; so yes, you could just read out the data for right-to-left splines in reverse, or gather the points into an Array and sort them by their 'time' element.

2) Yes, an Array is fine. The "translator" isn't an essential way of working - it's really just a memory/CPU optimisation by allowing the data to be constructed directly in the DSP's memory buffer (I didn't expose the buffer directly because it might not be a Float Array in the final version of the DSP code).

...however, I'll also PM you with my e-mail. I'm a bit busy with the ASM conversion at the moment, but if I can take a look at your code, I may be able to devise a "translator" that uses your collection of Splines directly, leaving you free to just work on the GUI side. If not that, I could at least give you some tailored advice about how best to handle the conversion.

Thank you very much, Trog!

Apologies for being a bit late to the party, but I've recalled a similar conversation about graphical envelopes that we had two years ago ...

viewtopic.php?f=2&t=10943&p=40015&hilit=lookup#p39936

My second offering (v17) is reasonably complete.

This was my first attempt at creating envelopes from arrays, made via graphics, using a simple dsp counter arrangement to scan through the tables. It works well, and I'm still using much the same method in HB3 (my pipe organ project) to this day.

Although I winced when I saw my early 2018 efforts again! It does have all the various elements separated out, though - hope that helps rather than confuses. The technique is 90% controlling the progress of a variable-speed counter using the stage numbers.

Nowadays I have everything integrated into an assembler block, in fact I've got two un-related envelopes integrated together with all sorts of added 'organ stop switching' enhancements. (Organ world). But it runs like lightning of course, this is one of the major advantages of this 'lookup' method because there's so little maths involved.

I've adopted two main methods for getting out of the 'early key release' problem. i) If we're, say, half-way through an attack then the solution is to sample & hold the current value, jump the counter to the start of release curve, and use the held value as a multiplier to act on everything right through to the end of the release section. This ensures no level-change glitch - you get a smooth release from whatever value has been sampled. Or ii) If the note has barely started, I've simply put the counter into reverse, which runs the envelope backwards, from where it is, to the zero point again. For my purposes these two methods work perfectly. There might be difficulties with more elaborate envelopes.

I too have wondered about using spline-generated shapes - exactly as tulamide suggested to me back then . Still on the to-do list!

H

HughBanton wrote:I've recalled a similar conversation about graphical envelopes that we had two years ago

I love the irony that, in your posts there, you expressed worries about having "reinvented the wheel" - it appears that in at least some respects, I have reinvented yours! The solution for smoothing an "early" release in particular is remarkably similar (let's flatter ourselves by saying that "great minds think alike"! )

Even the table lookup technique isn't so different once the staging logic is taken out of the recipe - the only major differences being that mine allows looping (so that the sustain section can have an indefinitely long "shape"), and that I'm interpolating between points (so that the time/mod difference between points can be arbitrarily large). Of course, there's a cost for those differences in my version, particularly working out the loop fly-backs (to be improved in the ASM version by skipping that code unless a node has been reached or the key has been released, I'm hoping).

The biggest difference is in how I work out the times by using a 'clock' signal, which is beneficial if you want rhythmic effects that can tightly lock to VST tempo - and utterly pointless if you don't! Only time will tell whether anyone actually finds that useful or not, of course; and, whatever ASM optimisations I manage, your solution would certainly be more efficient in most other cases (and quite likely more efficient than the stock DSP-code envelopes, I imagine).

All part and parcel of why I enjoy FS so much - it's always fascinating to see the different ways that people approach and solve the same problem.