DSP Robotics Support

R&R wrote:You don't by any chance still have the original DSP for the sync-master oscillator of: http://www.dsprobotics.com/support/viewtopic.php?f=3&t=36471&hilit=sync+oscillator#p109371
?

I believe that the ASM is the original sync-master oscillator, but I can reverse engineer that to DSP code.

Cool, thank you!
That would be really nice of you...

No hurry though, since I have gazillions of dropdown adjustments etc to make... before updating my LFO with more waveforms and minor updates... since my plugin is such a mess.
Currently at 2155 parameter prims. Will probably break 2300 soon. I guess 3000 is the next number to beat.

Might as well test how large a presetfile can get or maybe... schematically a Flowstone plugin can get...
But I suspect there has been made alot internally larger plugins.

Here you go. Whatever it may be good for. I included a (naive) saw output pin in the code version. Haven't noticed any drift wrt the stock saw prim.

Top!

Thank you MV, and happy new year! in advance

Here you go. Whatever it may be good for.

I know only that I know very little, and, well, you never know until you know... you know

Just testing some more of the Osc's that Martin here made. Which was used with the LFO that Spogg shared...



200%

Why did this even make me laugh...

FS should come with a warning label: "Use may cause spontaneous irrational outbursts"

R&R wrote:200%

Not sure if this is true, but it is definitely bad advertising of my stuff. I will have a word with the head of marketing.

...definitely bad advertising of my stuff. I will have a word with the head of marketing.

Never ever trust the marketing guys!

Must surely have been a typo considering your Sync Master (DSP) with the synceable polyBLEP Saws works 200% fine with my LFO. Didn't encounter any issues when testing a little...

So... 200% (up towards infinty) less drift in the PW square now

That's atleast 400% improvement i total. Tell that to marketing

Only weird thing was having to set the master phase to -0.5 and the saws to 0.5 to get an initial full cycle. Might just be the staging of the DSP...I probably just need to add an inital value somewhere. Works now anyways so doesn't matter

Just playing around... tried to separate draw method and the interaction of the toolbox knob (ruby).

Thought I was crazy (well, "even crazier"... ). Did the trigger lose momentum?

Should this even be happening with a simple last switch prim?
(there has not been any input from the wireless and Midi cc. They are not connected)



I do understand the root cause, sort of. I'm feeding back the set value to two separate ruby code, one feeding the other. I'm not being very nice to FS with my schematic Kind of the point.
I don't know but I would suspect green has it's own thread(s) and ruby, perhaps has a main ruby thread?
Just a little bit weird seeing different value on each side of a last switch. I guess the value has changed but the update event (trigger) was never run, or passed along with the value (in "flow" terms ).

I've seen selectors that sometimes needs a little bit of encouragement with an extra trigger

Spogg wrote:That knob is a crappy old one and doesn’t have default, even though there’s a property for it! I think it was made just to demonstrate the use of Ruby in a knob.

I’ve tried a lot of knob frameworks and the schematic contains my favourite which I’ve settled on for some years now. I’ve added a comment box to highlight the features.

Haven't gotten around to looking at knobs until now After doing a little structured testing with some ruby knobs I can see why it's a good idea to stay away from ruby knobs performance wise. Pretty steep performance hit, and it's not due to any rendering either it seems. Just the Ruby mouse-handling that seems to cost?

Spogg this was a really nice knob... Very good performance compared also to the toolbox. Which works really slow in my plugin.
So. Hybrid it is then... some Knobman to the rescue.
This overhaul is gonna take time. If i'm lucky I'll finish swapping out each knob... before I die of old age...

Edit #1:

Seems like there is a little quirk with this knob however. Right-clicking while holding down (dragging) left mouse button will break (freeze) the knob. Atleast in an .EXE.
Haven't looked into it more yet. Did try, without luck placing a right click that breaks connection with the dragY prim. But I suspect the dragY might be waiting for an end/left button up message... and stops any more mouse messages passed.

Edit #2:
Doesn't matter if I disconnect or feed another marea prims mouse messages to the dragY, the mouse prims seem frozen, or rather, the associated mgui doesn't pass mouse events any longer?
I don't know how to create own mouse events from Ruby to these prims, that would probably be a thing, maybe a last thing to try.
Probably the .EXE has a main mouse event handler... that's messing things up? Something to do with the .EXE zoom-context menu perhaps? Doesn't seem to fix the problem disabling .EXE zoom-context menu, but this disable probably doesn't ignore passing down right click down the code hiearchy?

Seems this quirk doesn't affect VST export atleast...

A little note to self...
Seems Bitmap and Bitmap Area Draw etc prims has a max file resolution limit of 64000px (guessing it's 64k).