DSP Robotics Support

So your´re saying green processing is perfomed at buffer boundaries?

The stream processing is only done directly after a new buffer comes in (from Driver or Host). So there is only a short stream processing time and then it's just idle. With a green trigger you can hit the processing time, but mostly you'll hit the idle time (because that's dominant).

BTW: You can read the ratio of Processing time / idle time directly: It's called "CPU usage"

MyCo wrote:The stream processing is only done directly after a new buffer comes in (from Driver or Host). So there is only a short stream processing time and then it's just idle. With a green trigger you can hit the processing time, but mostly you'll hit the idle time (because that's dominant).

BTW: You can read the ratio of Processing time / idle time directly: It's called "CPU usage"

Ok, now I get it. My counter is "counting" for about 0.1% of the processing time, then it´s holding the last value for the other 99.9% of the time, then a new buffer comes in the the cycle repeats - the mono2float primitives will, most of the time, get the last value.

Now... I´m a little lost regarding to the topic being discussed here... are we looking (again) for a way to have sample accurate green triggers? Or maybe we are looking for a way to generate sample accurate MIDI messages only? What do we need sample accuracy for? Because after reading the entire thread (and the prologue) I´m a little bit disoriented.

Tzarls wrote:the mono2float primitives will, most of the time, get the last value

That's right - and it is a reason why very fast or accurate ticks would be useless even if we could generate them.
It was shown before over at SM that when ticks become very fast, a green value can possibly change twice or more in between buffers - and so the stream cannot see some of the number changes.
Ruby is able to deal with this because it knows when the buffers arrive, and knows how many samples are in a buffer. The Ruby or "Rubified MIDI" events don't really happen "on time" inside the schematic, but Ruby DOES know at what index in the buffer to place the values - and instead of only the "last value" being read, it is able to collect many values into the array - and so the host or driver knows when they should happen when the data finally comes out of your soundcard, just by reading the array in sequence.
But to do that we need the new "Frame" components to correctly use audio inside Ruby - it has to process the audio as "blocks" so that it can keep track of the sample indexes. MIDI and Ruby "events" most likely use the event time to calculate the index of the sample where the event should happen.

billv wrote:Can you take a look if time allows...

Sure thing - that looks out of place, but I suspect probably just some dodgy Ruby coding!

Tzarls wrote:What do we need sample accuracy for?

Rough example.....
What if i wanted to create a "sample loop library" using the X11.
In order to sell them, I'd need to verify that the samples are "sample accurate".

Tzarls wrote:I´m a little bit disoriented

Yeh, it's a bit messy, big subject with lots of questions attached...sorry about that...

Tzarls wrote:are we looking (again) for a way to have sample accurate green triggers?

Not really, we all know that's "pissing in the wind". It's more like trying to discover why
the green stuff is contributing to a very accurate timing result, and how the threads are
communicating with an alien (ruby), and what sort of "influence" does Ruby really have...

Tzarls wrote:Or maybe we are looking for a way to generate sample accurate MIDI messages only?

In hindsight, now you say it like that.....probably clears up a lot of confusion.
Thats what I'm focusing on....getting that midi timing right on 100%.

trogluddite wrote:Sure thing - that looks out of place, but I suspect probably just some dodgy Ruby coding!

It's creepy.....stared at it in disbelief for about 5min....like a "Twilight zone" movie....

MyCo wrote:You can't meassure green with streams, because streams are processed in blocks

Thanks for hanging around.....your input is needed.

billv wrote:Rough example.....
What if i wanted to create a "sample loop library" using the X11.
In order to sell them, I'd need to verify that the samples are "sample accurate".

Speaking of which, I'm looking for some smart loop editor (for Windows, and for long audio files, not sample accurate, no regular beat or multiple beat inside), i.e. something that deals not only with zero-crossing points, but also with self crossfades (lenghts and types) of a clip (end with it's own beginning), and maybe offers some other useful tools. Any recommendations?

While biliv speaks about future, I'm being asked if I could start right now or better yesterday.