Playhead on multiple linked waveforms~ moves slower than audio
I've built a little multitrack recorder... there are 6 stereo audio tracks, so there's 12 waveform~ objects. I'm sending a line command to the top waveform (sync'd to the audio), and they're all linked, so they all show the line.
But I find that the line cannot keep up with the audio if I'm showing all 12 waveforms. If I resize the window so that only one or two waveform~ objects are showing, the lines stay sync'd with the audio pretty well. But if I resize the window to show all 12 waveform~ objects, the line slows down considerably, to maybe 40% of the speed that it ought to. (i.e. it's still not yet halfway through the waveform display when the audio has already finished!)
- All the lines do stay sync'd to each other, of course, and slow down at the same rate.
- The CPU usage doesn't seem to change when I resize the window to show all 12 waveforms. So I guess it's an issue with the graphics chip? It's an "Intel Iris Graphics 6100 1536 MB".
- Do I need to upgrade my laptop (MacBook Pro, 2.7 Ghz Dual-Core i5, from early 2015) to fix this problem? Or is there another workaround? Like, is there a way to link all the waveform~ objects without having them *all* draw the line?
if you have all buffers same length and display progress of all
tracks synced, you could place single multislider object over waveforms with hidden background and mode line to display the progress.
you scale buffer length to 0. 1. float.
but that would work only if you don't zoom, select etc in the waveforms
Thanks for the response! I now see
(a) how to make a transparent background color for an object, HOORAY
(b) I need to be using groove~ instead of play~
Thanks again!
if they are synced, they should sync.
the graphics card in my main machine is about 15 years older than yours and has 64 mb RAM.
when i sync 10 channels and display it in fullscreen it can happen that the lower 3 of them are always 1 pixel behind when the playspeed is fast - but programmatically the max objects are all on the same value.
in this concrete example i am using the "selection" - and not a vertical line - i think that looks better, but can of course only be done when you dont need the "selection" otherwise.
oh and i am using index~ with play~, and convert the index~ output to messages using snapshot~. (and in case you were wondering, of course those are 10 different buffers.)
Roman, I'm confused. If you're using index~, why do you need also need play~?
sorry, counter and index of course, i keep thinking index is the counter. :)
if you dont need to pitch, index is all you need for playing tracks and prevents you from coding floating point releated errors.
Ah, OK. At any rate, it looks like my little project is gonna work using a bunch of groove~s and sliders. I'm sure index~ would tax the system a bit less than groove~, but I'm thinking I might want to do some time stretching and pitch shifting at some point, so I'll stick with groove~ for now.
You could use 12 channel buffer, ony 1 groove object and matrix~ to control volumes.
Recorder could be a single stereo type, and assignable to 1 of 6 stereo tracks.
Hm. I'm recording the tracks one at a time... not recording an ensemble all at once or such. Could I do that with a 12-channel buffer?
Anyway so far my groove~ based recorder seems to be working out alright.
Thanks!