Holiday notice: Cycling '74 will be closed on Dec 25th, 26th, and Jan 1st. Manual authorization, support cases, and manual order processing will be delayed.
Progress bar (& time elapsed) for *gasp* sfplay~
Mar 03 2013 | 3:15 pm
Previously i asked about getting progress bar with waveform view for buffer~ and groove~. I also wanted a CD player style display of the current time, which i was able to work out with LCD fine. I asked this because needed to know where I was in the current file, in order to make some decisions during live performance depending on what files is playing and how far along we are in that file what amplitudes are on the horizon, etc.
AND because I thought this would be way easier to do with a buffer already present for waveforms to be displayed.
But, in the case that you are playing long, large files it really is preferable to use sfplay. This strikes me as a much harder problem and the idea of having a waveform overview is likely unrealistic (and would perhaps need a buffer anyway, defeating the whole purpose and advantage of using splay.
So, like my buffer/groove patch I have a fancy drag & drop loader for sound files (see and be impressed haha) using the drop file and a jit cellblock (ooh, and yes it scrolls!) and I have my sexy LCD which shows the time elapsed like a CD player. But I fear the progress bar part is where I run out of max knowhow.
-kp--
- Mar 03 2013 | 3:18 pm(sorry, somewhat ugly and the dropfile and jit.cellblock (i just noticed) are misaligned (tho still impressed by that construct. awesome to have a scrollable sound file browser right in your patch)).
- Mar 03 2013 | 3:20 pm(& yes, i wrung my paws over that other patch only to realize that one of the pieces has a super long high res series of recordings that chokes the memory on my machine using buffer~)
- Mar 03 2013 | 7:03 pmI can't help with a waveform view, but here's a progress bar:
- Mar 04 2013 | 2:45 pmThat is awesome. Tricky stuff in that subpatcher. I can't help but wonder if this kind of helpful visual feedback and data could not just be rolled into the objects themselves in the future. Lots of folks want (or need) to play along with patches and it also helps in rehearsal for piece that are instrument & fixed media. Anyway, this is really helpful. I made the progress bar bright and with some ghosting and put that against the black background and in presentation mode you can stand away from your laptop and play and still see where you are approximately in the sound. Thanks for your help.
- Mar 04 2013 | 6:42 pmWell, much of that complexity is because I hate using delays to wait until things are settled. Here's the same thing, more or less, that uses the "getnamed" method of sfinfo~. The delay comes into play because one has to wait until sfply~ loads its cue until sfinfo~ can query.
- Mar 05 2013 | 12:15 pmThat was how i was trying (and failing) to do it as you could probably see by the name message and the sfinfo lying stranded in my patch. I disconnected everything before posting to save myself some embarrassment but I like your first approach and am happily (already) using that but it is nice to see that I could work the other way too. I humbly summit that in 2013, splay, play & groove could all use some new features. :) but I am already pretty stoked about polybuffer and the sound quality improvements on play so i'll shut my pie hole and get back to work. Thanks for your help on this. A Waveform overview will be something for the future, in the mean time this is working wonderfully for long files and is very useful. Thanks!
- Mar 05 2013 | 4:04 pmSeems to work better without the set $1 message to the multislider. I snipped that connection and went right from [/ .1] to the slider and it still works fine, esp as we are not not using set to do anything (tho using set in the multislider to set playback position would be kind of cool)
- Mar 05 2013 | 6:34 pmI had started to carve in the "slider sets position" feature, but ran up against sfplay~ not liking the seek message when driven with a sflist~.
