Scope's in FS

[Drnkhobo]

Hey all, ive been trying to get an accurate scope going & have come up short.As it stands I would like to get a snapshot of the audio every beat. So far with the amazing work of Billv, Nubeat7, Trog & others its now possible to have accurate timing from the host.

My process is this:

Calculate the required samples needed for the snapshot (get beat length in samples)
Then with the help of a good timer, trigger the mono2graph every beat.

Each time its slightly off. Nothing I do seems to grab the sample in the same place. It keeps bouncing around.

Have a look at the fsm

Test Beat.fsm

(117.51 KiB) Downloaded 1155 times

Export it to vst, load up in host.

Whack in a 4/4 kick pattern and hit play. Technically speaking it should grab the kick sample very beat . It does, but it keeps jumping around on every beat.

Now if you program a kick only on the first beat & then hit play. . . you see that it grabs EARLY (beginning of kick at the end of sample window) & on the second beat shows a grab thats too late??? Annoying!

I tried to make the fsm as minimal as possible to reduce the amount of human error

Dont know where to go on this one! Its either 2 things: Timing off or delay in graph

Im pretty sure that the timing is not an issue:
http://www.dsprobotics.com/support/viewtopic.php?f=3&t=1255
http://www.dsprobotics.com/support/viewtopic.php?f=3&t=1267


So does anyone have experience with graphs / displaying signals here?
Any help would be greatly appreciated!

[MyCo]

There is no way to make this work with green triggers. The only chance is to use Ruby and its audio frames. But that'll use a lot of CPU.

[Drnkhobo]

But why MyCo. . . WHY
Its so close. . . just a few samples jumping around each time

[MyCo]

But why MyCo. . . WHY
Its so close. . . just a few samples jumping around each time

Because green data isn't sample accurate... it's processed whenever the CPU has time for it. Also the "Mono to array" primitive captures samples block aligned, when your sample buffer is very big, you'll always capture only the beginning of the buffer, but never the samples that are somewhere near the end.

[Drnkhobo]

you'll always capture only the beginning of the buffer, but never the samples that are somewhere near the end.

I see. . .

I mean, its no problem if you have a full track running (the display will be 1 beat off but thats fine). Just the constant moving of the graph. Maybe a Ruby routine with Arrays can help to keep it in place?

Because green data isn't sample accurate... it's processed whenever the CPU has time for it.

I was under the assumption that the beat ticker is done in Ruby??? Its getting excellent results just little jumpy.

[tester]

I don't know details of your project, but what about some smoothing/averaging over time? Slower but more accurate display for more constant patterns? I used "green buffer" for pitch tracking instabilities. Not perfect, but depending on your needs - the idea can do the job. Is somewhere on this forum.

[Drnkhobo]

Thanks Tester Will look into it!

[billv]

Because green data isn't sample accurate

In Some Seq systems I've built, they use green counters before feeding back into midi.
Sample accuracy is maintained, and well documented.
Myco, is the only reason i'm maintaining sample accuracy here,
is because green section is within a "Ruby" loop, so to speak????

[MyCo]

No, sample accuracy isn't maintained. As soon as your timing path relates on a green connection, your sample accuracy is gone. There are only 3 types of connection which are accurate: Ruby (V), Midi (M) and streams. When you use something else, your accuracy is depending on Windows and CPU usage.

[Drnkhobo]

There are only 3 types of connection which are accurate: Ruby (V), Midi (M) and streams.

ok, so will it be accurate if the timing & drawing is all in Ruby?