DSP Robotics Support

When you inspect the ASM code of a DSP codebox, you will often find unnecessary moves: This can be a problem for long formulas like evaluationg a higher degree polynomial, where the compiler might run out of xmm registers. Note that you won't get a warning in that case!

martinvicanek wrote:This can be a problem for long formulas like evaluationg a higher degree polynomial, where the compiler might run out of xmm registers. Note that you won't get a warning in that case!

Good heads-up if I ever get to the point of prototyping more mathier stuff. That overwriting would probably taken me a while to catch... or rather would probably have thrown something out the window

Hmm... so basically I have entire oscillators worth of unnecessary movaps just in all of my synths multi input "range checks" spaghetti (summed together) alone
I don't know if I should consider this good news or bad news lots to do then...

Also noticed I've neglected to multiply by samplerate all over the place in my synth. Guess i'll just have to keep going as i'm already in the process of fixing that issue now

I spot also a strange thing in your code, don't know if it's normal, maybe some ending line are missing ?

With those 2 last :
movaps xmm7,[ebp+4224];
movaps xmm6,[ebp+4208];
you move a memory to an xmm location, but those xmm seams to do nothing with it, are they really necessary ?

Tepeix wrote:you move a memory to an xmm location, but those xmm seams to do nothing with it, are they really necessary ?

Yep looks funky... the code wasn't meant to show anything more than an approximation of unnecessary movaps.
Abrupt ending might be that I disconnected the module from its output to connect the analyzer

I've had chance to convert some more spaghetti to ASM now... with nice results. In some cases more than 1% less cpu when pushing 64 concurrent notes with a selected reference patch. Meaning, on my computer probably 4 to 8 more voices added to max playable voices, depending on set buffer size though. Still nice!

Finally! Version 0.51 of my plugin available...

Done converting enough spaghetti to ASM and was able to add some internal filtering. While maybe reducing CPU usage at the same time. Nice.

Amongst the updates I had some fun with MV's Noise oscillators in the synths Aux Oscillator. Adding tracking filters to them as well

Also added an easter egg in this version of the synth for forum readers:
Has to be done on each preset (EDIT: now retained across presets), but going into About and clicking Saguaro's like a boss glasses 7 times (but less than 14) will unlock a prototype Osc Module temporarily named "Karplusplus" (EDIT: renamed to "Karplus-Strong Whiskey"). Didn't get this Osc Module to work correctly at 96khz or higher, and maybe I wont ever be able to. But, there it is anyway. Maybe fun for a few minutes


Question to MV...
Had hard time figuring out how to make the Noises work with my seed selection with voices and all that
This time I ended up dividing and running two different Velvet Noise Osc's simultanously, one variant with some added ASM, and another variant with the "RNG channel stuff and padd ops for the state" removed... in order to make Aux Oscillators seed selection work as intended.

But to the question... You don't by any chance have a guess of what seed for Velvet Noise would generate the shortest time possible until the initial first impulse? Or some ASM trick to always generate an initial impulse?
I'd really like to make the noise playable when my synths S1 knob is at minimum However I don't think I would ever be able to work those shifting ops and additions backwards to find a decent seed number

Well, you have the grid spacing parameter T which is something like 10 to 15 samples (for 44.1 kHz sample rate). The first impulse will occur somewhere in the first grid, so the delay will be at most T samples (half of that on average). BTW the starting point will be different each time and for each SSE channel (or note in poly), which is kind of intentional. But even 15 samples is a pretty tight latency (0.34 ms), I dare say negligible. Is that a problem in your setting? Do you want the first impulse to happen immediately? Each time, for each note?

martinvicanek wrote:Well, you have the grid spacing parameter T which is something like 10 to 15 samples (for 44.1 kHz sample rate). The first impulse will occur somewhere in the first grid, so the delay will be at most T samples (half of that on average).

Aaaa ok now I see! (output:ed time and idx to see)
Hmmm... maybe I might be able to MacGyver it then

In my scenario I think (me and math ) it looks like the spacing becomes (15*100000)/10±5... so that leaves a grid spacing of 3.4 seconds

martinvicanek wrote:Do you want the first impulse to happen immediately? Each time, for each note?

Yep!
I'm guessing making the idx 0 or 1 or something "initally" (when T is 100000) and then immediately going back to the actual input T (5 to 100000) might give the ideal functionality.

Did a brief test...
Hmmm. Ok, so making T = 0 at stage0 and then afterwards T = 100000 won't work it seems, since only the first active poly stream gets immediate impulse.
This must be due to the 4 channels then?

Ah, so you apparently use velvet noise with large T for control signals, not for audio. The simplest solution would be just add an initial pulse to what you already have (see attachment). Makes sense?

This is great, thanks!
After failing to get the velvet to retrigger an inital (im)pulse... I was starting to contemplate adding "something" extra to add in parallel the 2 velvet osc's etc to achieve my goal.

Already use elaborate (for me atleast ) schematics around your regular white noise (as random generator) in the LFO randoms waveforms/sources. Only way I could get things to work there, as I wanted
But things started to get real messy when I added ability to adjust seed by knob, and on top of that adding odd/even voice stuff.

I've started experimenting a bit with yet another rand detune voice mode in my synth, that will be named spread across. Hopefully a bit more like a regular unison spread. But things are starting to touch the subject of supersaw and such... since I immediately encounter to much voice/phase "beating" etc. Have to take a look at Adams paper, and if there is some active filtering I can employ etc etc...

martinvicanek wrote:Ah, so you apparently use velvet noise with large T for control signals, not for audio. The simplest solution would be just add an initial pulse to what you already have (see attachment). Makes sense?

If by control signal you mean something to get your ZDF's reso ringing, then yes (ducking the volume to 1/100 at high notes )

So... putting this beside your Velvet Noise won't cause a double inital impulse/burst at some point? Iow if they output at the same time?... Or does the velvet noise never output on the first/ealiest samples, ever?

If velvet noise does output on for example sample 1 to 16... I could just add a delay on it, but seems a little costly.