Cabbage Logo
Back to Cabbage Site

Ian McCurdy's LiveBufferDisplay.csd mods

Hello,
I’m modifying Ian McCurdy’s LiveBufferDisplay.csd by adding a moving pointer to mincer (with some control on how the buffer is played back) but it looks to me that there is no sync between the slider indicating the pointer and the audio played back (first slider below the table display, channel “ptr”).
It’s normal (due to gui refresh rate) or there is something i can do to improve the table reading part of csound (around line 172 of the file attached)?

Any suggestion is more than welcome

Ciao

Stefano

LiveBufferMassacre.csd (4.9 KB)

Do you mean that the slider indicating the current position in the buffer does not relate to the start and end sliders? How smooth things appear on screen is largely dependent on the guirefresh() rate. The lower this is the better the GUI responds, but the more CPU that is used up. At normal speed the instrument seems to move between the start and end points without any noticeable issues. But at higher speed it starts to look less synced. The audio will be fine however. No need to worry about that.

Finding a generic solution to the graphics issue is not easy. If one really needs to have a GUI control that updates very fast, it’s best to write a new control in C++.

I was guessing a problem related to gui refresh, I needed a second opinion, big thank you :smile:

I took another look my example as the method used seemed a bit hacky and limited. The new version can be found here:
http://iainmccurdy.org/CsoundRealtimeExamples/Cabbage/Effects/LiveBufferDisplay.csd

In this instance I don’t think guirefresh is a big factor. More significant was ksmps=64 which was giving a somewhat stuttering waveform update (ksmps=16 seems better). In the earlier version, changing ksmps would affect the audio buffer duration but this is fixed in the new version. The display buffer/table is now set to be the same size as the table widget is in pixels, which seems to make sense in terms of logic and efficiency. I’m not totally happy with how this renders graphically - I think this is largely due to the fact that the table used by the widget is quite small. I might look into a way around this.