DSP Robotics Support

I crack myself up

Here's a kind of a unnecessarily elaborate latch switch logic, using counters. But can be used with simplest trigger buttons. Doesn't cause loopback so state can be set directly. Might be useful to someone even if it's a bit funny...

Edit:
LOL have to make a proper one, since I have to doubleclick the changed knob twice...

And with that...

Here's a question for the real coders:


This will stop sending trigger halfway of a knob.
I block triggers this way when I use like... log10 and some "power" operations afterwards, that aren't needed for half knob turn... this seems justified.
But how much green does one really need afterwards to justify this, and the constant overhead of running it?
Log, power, or a whole bunch of divisions maybe?

Aaaaaw...

The capitulation version simply using the buttons Ruby box to store value/state as usual instead.

Anyone more clever than me (setting the bar real low here people ) know how to do this latch without storing button states in Ruby box, and yet allowing for loopback?

Hmmm...

The Alpha thinks this is a problem, but old FS does not...


So the logic would be that update to the list cases a trigger in the Dropdown prim outputs. But this isn't an issue with old FS?

R&R wrote:The Alpha thinks this is a problem, but old FS does not...

Easily fixed with a S&H... But clearly a difference between FS4 and old FS.

Guessing this is the only easy way of getting last played (midi received) note's velocity in green?

Here is an alternative (FS User Guide p.219f):

(Note: To avoid confusion: The MIDI message displayed in the lower Ruby panel (Quick Watch) is not a "note on" but a "note off" message, hence the different velocities.
Note On: 93 (green output)
Note Off: 19 (lower Ruby panel)
I could not manage to sustain the note while taking the screenshot. )

martinvicanek wrote:Here is an alternative (FS User Guide p.219f):

That's definately more neat, code-wise...

Wonder if Maik has hidden any treats in the Voice-type stream, thats not available... or if it's just not implemented at all under the hood

Hmmm, along those lines... some poly stream values that could be passed along each stream would have been practical. Maybe i'm just unaware if there already is such a thing in FS.
Might have been to costly on the CPU perhaps...

R&R wrote:Hmmm, along those lines... some poly stream values that could be passed along each stream would have been practical. Maybe i'm just unaware if there already is such a thing in FS.
Might have been to costly on the CPU perhaps...

Not a green question. Breaking my own topic



I'm so slow
Could just sacrifice resources by using more Poly's and filter out by Id, or perhaps by any other arbitrary value I guess...?

Anyone used an "early in schematic bus creation" type of scheme in elaborate more global way in any of your FS plugins?