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 (or time elapsed) for buffers (play~/groove~)
Feb 28 2013 | 8:01 am
So I am using polybuffer~ and groove~ (or sometimes play~) and picking legthy sound files algorithmically, some field recordings, some other stuff, etc.
I need to know what file it is playing and how long it is, and that info is pretty easy to display with info~
But also need to know where we are in the file, some output of the current duration, like time elpsed on a CD player or a progress bar. Since I need to make some descisions during live performance dependeding on what files is playing and how far along we are in that file.
I thought that this would be a common requirement and easy to do... I thought you could do this with the playbar, but the playbar is not a progress bar but is used to trigger a sound (it doesnt come out of a sfplay~ object but is put into one to control it)... further it doesnt display time AND it doesn't work with buffers (play~/groove~) only sfplay~..... a final wrinkle is that some soundfiles play at half speed (or so) and some play in reverse.... ack...
Turns out this is not common? or trivial? Anyone ever do this?
-k
- Feb 28 2013 | 10:19 amgroove~ has a loop sync output which can be used to indicate position:It would be some work to factor in play speed and direction, but not too much.
- Feb 28 2013 | 11:07 amwoah.Thank you! & that is neato.I totally misunderstood what loop sync output does. I thought that it had to have a file with loop markers in it to even work.why is [change 0.] needed?
- Feb 28 2013 | 11:25 am
- Feb 28 2013 | 11:28 amThis patch uses polybuffer~ You can drop a folder of soundfiles on dropfile and it will load up the buffers. Then you send it a bang and it choose a random buffer and plays it. What I added to it was merely some visual feedback so I could understand what it is doing. I tried to integrate what you had there but that scheme somehow doesn't seem to work with polybuffer~ though it works great with a regular buffer.Also: There is an off by one error. It displays not what the current sample playing is, but what the last one was. I can't seem to find what to jigger to make it report the current file.
- Feb 28 2013 | 7:29 pmThere was a little order of operation issue in your read_sample sub patch. You were banging info~ before you set the buffer.Also, you need to set the waveform~ object to the same sample as is playing.
- Feb 28 2013 | 7:51 pmThanks. That is cool. Did not realize I was banging info~ before setting the buffer. Duh.Why does it always complain when i open it for the first time that it can't find & load the files that I happened to be using it last time I used the patch. I always try to have a clean error free max window when i first launch a patch and this is wigging me out.Pretty cool. I am so excited about that progress bar. Sexy stuff.Thanks!
- Feb 28 2013 | 7:53 pmbtw, waveform~ can display its own cursor, so there is no need for click-ignoring multislider (see 'line' message and 'display' tab in waveform~ help).
- Feb 28 2013 | 9:12 pmTrue, but with a separate multislider you can play with the position in the sample by clicking in the display, like this:
- Feb 28 2013 | 9:59 pmAnd here's a version that doesn't throw errors when opened.
- Mar 01 2013 | 12:54 amHa! The LINE message! Jesus! Is it there eversince? I don't know how often i have put multisliders over [waverform]s..*really* many times, and then of course calculate the correct offset if you zoom into the waveform, mhh one of my favorites.. while it still has some advantages to use multislider in some cases, sure.. Thanks for letting me know about the line message!
