DSP Robotics Support

Hello,

I want to trigger a graph modul exactly when a note on is received or when an oscillator starts to run. I do not want to use a timer or tick modul as trigger.

Is it possible to generate a trigger from a stream or audio signal. For example by comparing a signal with a float value (0.0 or 1.0) or another signal. If the condition is met, the triggering should take place.

My goal is to extract sampled data with a graph that exactly match the sampled data at the trigger time. The sample data array should begin with the samples at the trigger time.

(At the moment I can only work with a workaround, which requires that I evaluate two signals later with the sampled data from the graph module with 2 inputs and thus determine the exact starting point. But for this I have to read much more sample data as normally needed.)

Do you have any ideas?

I’ll offer what I can…

When you want to go from the live stream world to the green world you have to use the M2F (mono to float) prim. That means you need to supply a green trigger to update the conversion. So immediately you’ve broken your requirements not to use a ticker! The green world is far from sample-accurate, since it relies on the lowest priority for evaluation. That causes limited accuracy and repeatability.

If you compare a stream value with a float value of 0 and give a 1 output when a sample is exactly equal to 0, you may not actually get an exact 0, because the stream may contain very few samples with an exact zero value. That means you would need a DSP window comparator which gives a 1 when the stream falls within a range you specify. So, once you have a 1 output when the samples fall within your set range, you can use the M2F prim to convert to float. Then on the M2F output you put a Greater than prim with a reference value of 0.5 so the green bool output operates reliably. Then, after that, you would put a Bool to true prim to create the trigger.

There are many issues with this method. You’d need to select a window with a range wide enough to create a 1 output for long enough to guarantee the M2F would catch it. Also, if you have say a pure square wave input, the window would likely be too narrow to create a usefully long 1 output.

Another approach would be to use an envelope follower followed by the same M2F system. That would create a trigger by the amplitude exceeding a low value. Of course, the envelope follower would have a time delay, an attack time, which means it would never trigger at the exact start of a signal.

I often use the Signal Analyser prim for precise timing analysis. That is, of course, an offline method.

If you need to draw a graph in real time, note that your screen is only updated every 20 miliseconds or so, so you will have to live with some latency anyway. You could buffer the signal using the Wave Write Mono (R&D) prim and then draw whichever part you want to look at.

FS_User4711 wrote:I want to trigger a graph modul exactly when a note on is received or when an oscillator starts to run. I do not want to use a timer or tick modul as trigger.

I don't understand, why this would matter in any way? An audio signal consists of 44100 values per second. Nobody has ever drawn a graph with that many pixels per second. Instead they display an rms, which makes much more sense. If you use a DAW, you know how that looks. Zoom out and you see 4 minutes or so of audio on a screen with, say, 2000 pixel width. But 4 minutes are 10,584,000 values. Only every 5292th value is actually displayed.

And that's for a reason. You can't display realtime audio data, without reducing the amount of data to display. And the display may start like 30 ms too late. The user doesn't notice it, and the display is still fine, because at that point only 1323 values have past, so the drawn graph still looks the same.

Thank you very much for the helpful answers. I really appreciate it.

I have now managed with an auxiliary signal trigger and a bit of Ruby customization in the Oscilloscope to get a quasi-still signal at the trigger time. Attached is the fsm file for this.

(I don't want to read larger samples, but I would like to be able to see quasi exactly what comes out of my synthesizer or how this affects the output signal when receiving a single midi note. And preferably at a fixed start time that is independent of the waveform and start phases).

In this environment I noticed that the trigger of the "incoming notes" module probably does not work with a timer module. I have attached an fsm file for this as well. (If you press the trigger button the timer starts. But a timer does not start if it is connected with the trigger of the incoming notes modul.)
Is this a bug? Or have I done something wrong?

Many thanks again for the hints.

Try this logger.

The thing is that green is never accurate. Green triggers are controlled by a Windows queuing system. Execution takes place when there is time for it, and that depends on how busy your computer currently is. You may get hundreds of triggers executed per second or jus a few.

Wow, thank you so much.

I tried the logger today. It really works great.

I have operated the logger for test purposes 8 times together with 10 oscillators. There were no speed problems. (With other oscilloscopes I had partial sound dropouts).

Thanks again.

martinvicanek wrote:Try this logger.
...

I have!
It’s a potentially really useful tool having that trigger input.
My toolbox has been suitably enriched!
Thank you Martin.

As always, my question got ignored (sigh). I'll try it again.

Martin, Spogg, anybody else, can you give me a real world example, where it matters, if you see sample #0 at trigger - and not sample #-1 or sample #3? Let alone that you can't even draw the difference between 0.1 and 0.10001?

I might be considered stubborn, nosy, even dispensable. But if you can't answer the question, it means there is no application for it. And that would mean, it's impractical to even try.

For me this is interesting, to be able to analyze a signal in full resolution in retrospect.
For real-time applications, this is certainly not necessary. I would rather use this as an analysis possibility, for example to be able to detect the smallest differences between signals or errors in my implementation. So that the starting point in the display does not always shift, I looked for an appropriate solution.