DSP Robotics Support

hello,

I'm taking the liberty asking how to deal with two "last minute" difficulties (see the attached .fsm)

1.
Since Flowstone 3.0.3, the mouse doesn't transform into an hand when hovering the buttons and selectors.
This is because of frames (graphics), for delimiting the outline.
With Flowstone 3.0.2, even with those frames, the mouse did transform into a hand when hovering all buttons and selectors.
What do I need to do, for getting Flowstone 3.0.3 acting like Flowstone 3.0.2 ?

2.
Since the beginning, I have a problem with properties.
I can enable/disable the "property" attribute of each elements that's supporting the properties concept.
Unfortunately I don't know how to "hide" the properties, when defining elements as properties & not willing to have those properties showing in the top-parent properties panel.
Here and there I have seen modules carrying a special tag replacing the "P", indicating that there are properties defined inside the module, with as effet that those properties won't show on the top-parent properties panel.
How to do this ?

Thanks in advance
Cheers,
Steph

It looks like if you strip all of the mouse related code out of your frames ruby code, then the mouse pointer behaves as you want it to. I'm not sure why you would have had mouse code here to begin with, since it looks like these are just to make the application pretty.

On your second issue, if you enable the properties panel for an object, then the properties defined inside it will not show up in the parent object. Since you mostly have all of the properties panels turned off, you end up with a mess in the parent object. When you enable the properties panel, then unlock it, and you may see some red lines, which indicate that the properties are off the edge of the panel. Resize the panel to be able to drag these items into a proper location.

Hello Michael, thanks you so much taking care of this.
Here is a minor upgrade embedding the changes you advised, plus a new "open Scope" button at the bottom displaying the time-domain signals. Currently I'm only using such modality when sending a Dirac pulse, otherwise Flowstone crashes because of CPU overload when drawing lots of lines on screen.

The screenshot is the transfer function of a Logitech z120 speaker.

I'm perplex seeing the huge delay counting in thousands of samples between ch1 setup as "Gen" and ch2 setup as "Right-In". I can understand there is a delay because "Gen" is in digital domain, and "Right-In" is delayed by the USB link, sound card DAC, sound card ADC, and USB link again (actually, I'm using an USB audio card). However, a delay close to 10,000 samples looks insane to me.

As soon as the CPU gets loaded (say 30% CPU usage), the ch1 to ch2 delay appears to vary somewhat in a random way. This happens with the Scope being triggered by the green central trigger "do_fft". Thus, the green Triggers are far from deterministic, far from realtime. Surely the scope gets triggered by the central "do_fft" trigger, but surely also, Windows and Flowstone Green machinery are taking a certain amount of time - quite random - to execute such synchronization. When looking at the ch1-ch2 waveforms, it appears that the random delay introduced by Windows + Flowstone Green is between 50 ms and 150 ms. Is this pathologic, or is this to be considered as normal?

How would you organize the Scope trigger for a) some Blue DSP code generating a Dirac every second or so and b) the Scope being precisely triggered by such Dirac, for the Scope always grabbing Dirac at the beginning of each frame, then grabbing the 256 - 512 - 1024 ... next samples? Currently I can't do this as the Blue time doesn't correspond to the Green time. Do I need to implement the grabber in Blue (DSP code)?