Why? I'm asking myself: why I took this as a challenge??? I just made readsf.meh~.
It works similar to readsf~ with some changes.
- It is prepared to read stereo files.
- Optional argument: miliseconds for the metro to output the time
positon. Default 10.
- Open files with [open file.wav(
- Starts with [start(
- Stops with [stop(, but, when [start( is sended after [stop(, it opens
the last file and start playing it (can have a delay of loading, maybe an unsynch of timer, I didn't check it. The same as when the file ends)
- Pauses with [pause(
- Resumes with [resume(
Outputs:
1- output left 2- output right 3- status (symbol): loaded, playing, paused, stopped. 4- minutes (int) 5- seconds (int) 6- miliseconds (int) 7- time position "minutes:seconds" (symbol).
When I use this and check it is version 1.0, I'll upload to forum.
El 09/10/13 22:05, Mario Mey escribió:
El 09/10/13 18:08, IOhannes m zmölnig escribió:
On 10/09/13 20:49, Mario Mey wrote:
Sorry, I meant that I wanted to know the *time position* of the file, while playing. I know that I can put a [timer] and reset-activate it when readsf~ starts playing, but I would be great if readsf~ use the mostrigh outlet to output this information (always or when asked for it).
why?
or rather, why don't you just create an abstraction [meyreadsf~] that wraps the [timer] logic (and share it with the community)?
Well... it's a good idea. I use readsf~ with switch~ to pause and unpause it. It can be all transformed in an abstraction. I don't need precision and my 20 minutes song doesn't need to be counted... but if readsf~ is precise with time position, then, the new abstract will be too.
*Is readsf~ precise?*
If/when I make that abstract, I'll share it, of course.
gfmaf IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list