DSP Robotics Support

i`m not shure if this helps but with the mono to frame prim which also have the rubysamples input you can tell how much samples it should read or? viewtopic.php?f=2&t=1084&hilit=mono+to+frame

Mono To Frame winth input for sample lenght
here is limited to max 4096 sample

ah yes , ok i didn`t know that, iwas searching for it in the user guide but there it don`t exist?

i also was thinking about what the ruby sync primitive is doing exactly, because in the userguide yoou can find this:

"However, what you do need is a way to sync the Frame output with the Mono stream and also a way of
finding out the required frame size. This is where the Frame Sync component comes into play."

is it generating a framesize? or is it given a required frame size? because inthe example from the user guide there is a frame to mono on the output (which would need an asiobuffer frame size or?) so this confuses me ... how the sync prim knows what size is required? ... sorry i `m afraid its not really helpful for this topic too

Frame Sync
the info in your output say:

"An event with size of the frame (sent precisely before the frame is processed)"

I have this scm from SM given by Trog. It is their attempt at a good ol scope. Its pretty awesome, but the thing is its not without bugs. He suggested changing the timing to be in Ruby but I have no idea how. . . .

The problem stems from the correct buffer size grab. As soon as you change the delay amount it messes with the scope.
Have a look:


First notice the wet signal in the scope, then turn up the mix amount in the delay. . .
Try changing the delay amount setting, while you move it, the scope acts like its only displaying dry (not the delayed signal) & when you settle on a delay amount, it displays it wet (which it should)! But you get that gap of where its "dry" so its hard to tell the difference when checking back on your scope. . .

The buffer is detected by midi (i think) so maybe someone here knows how to grab the Frames & stitch them???
Have a look in the "get buffer" module . . .

Have a look at that:
http://synthmaker.co.uk/forum/viewtopic ... 10&t=11773

It triggers sample accurate. But to allow this it uses huge hacks so that it doesn't miss a single sample. That's also why it uses a huge amount of CPU.

Ouch! Its damn nice MyCo!
Its for DSP pro's though . . .im just looking for a semi-pro scope

To come back to what I wrote:

MyCo wrote:That's actually something that I noticed, too. And it took me hours to find the reason for that. It's actually a problem with Ruby frames, they aren't synchronized somehow. I reported that to Malc already...

Malc found quite soon the reason for that problem. He probably could fix that in no time, but then we found out that the solution is just not the best way. So now he plans a general change in how frames are processed which could take longer. But the result would be much more stable and it would give us a real stable (slightly delayed) timing for Frame-I/O.

So now he plans a general change in how frames are processed which could take longer. But the result would be much more stable and it would give us a real stable (slightly delayed) timing for Frame-I/O.

Fking awesome!!!!!!