Hi all,
I'm looking for some external that can play mp3 files with variable speed. I know about readanysf~ but it seems it's linux/osx only (I use windoze). Is there anything similar available on "my" os? Or maybe someone somehow got that readanysf working on win?
Any help will be... helpful :-)
cheers, Bart
hi bart,
i recommend searching pdb for hose kind of questons: http://iem.at/pd/pdb/query.html?all=y&alb=y&qry=mp3
Max Neupert :
i recommend searching pdb for hose kind of questons: http://iem.at/pd/pdb/query.html?all=y&alb=y&qry=mp3
I already tried that. Haven't found anything suitable though :-( . Also, this database doesn't seem to be complete anyway.
cheers, Bart
hi,
is generating temporary .wav files a practicable alternative for you ?
then you could use "system" from the motex library to do an mp3->wav conversion with some command line utility like "lame" and load it into a buffer for variable speed playback. after use you can delete that temporary wav file within PD too (with a dos command to "system").
of course this isn't a really cool solution, and there is a time lag for the converion stuff
i think thomas grill has made some harddisk-playing external a while ago, but i don't have it i haven't heard of anybody working successfully with "readanysf~" on windoze yet.
ciao
oliver
Bartlomiej Bazior wrote:
Hi all,
I'm looking for some external that can play mp3 files with variable speed. I know about readanysf~ but it seems it's linux/osx only (I use windoze). Is there anything similar available on "my" os? Or maybe someone somehow got that readanysf working on win?
Any help will be... helpful :-)
cheers, Bart
oliver :
is generating temporary .wav files a practicable alternative for you ?
then you could use "system" from the motex library to do an mp3->wav conversion with some command line utility like "lame" and load it into a buffer for variable speed playback. after use you can delete that temporary wav file within PD too (with a dos command to "system").
of course this isn't a really cool solution, and there is a time lag for the converion stuff
Yeah it isn't cool at all, but propably I'll end up doing something like this. First I thought about converting all the mp3 files to wav, but your idea seems to be better. On the other hand, I don't know if calling some external command line tool while pd is processing audio, won't cause any audio dropouts/clicks/etc. I want to fit pd, sound & graphic files on to my 512MB portable USB memory, and using .wav as sound file format makes it somewhat impossible (due to a number and size of these files). Also a friend of mine asked me if I could build for him a mp3 "dj mixing" patch (something like NativeInstruments Traktor). Well, I think I'm going to try your solution for now.
Anyway, thanks for suggestions.
cheers, Bart
Hallo, Bartlomiej Bazior hat gesagt: // Bartlomiej Bazior wrote:
Yeah it isn't cool at all, but propably I'll end up doing something like this. First I thought about converting all the mp3 files to wav, but your idea seems to be better. On the other hand, I don't know if calling some external command line tool while pd is processing audio, won't cause any audio dropouts/clicks/etc. I want to fit pd, sound & graphic files on to my 512MB portable USB memory, and using .wav as sound file format makes it somewhat impossible (due to a number and size of these files).
You could convert to ogg and use Olaf Matthes' oggread~ external. There is an mp3play~ object in the IEMLib, also on CVS. I have found, that it doesn't like to play many of my mp3 files, though.
Both objects are not really fit for doing DJish synchronization let alone beatmatching. For this, only readanysf~ comes close, however not close enough for my taste.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht :
There is an mp3play~ object in the IEMLib, also on CVS.
Yes, I know about that one - no "speed" control, though. But a moment ago it striked me, that using variable speed mp3 playing external will propably cause me a bigger problem. I was planning to use that kind of object to play various sound loops - my patch works more less like ableton Live, where I trigger those sounds by midi events. The patch has bpm control which controls the speed at which all the files are being played (that is why I asked about mp3 playing external). But now I remembered that mp3 encoders do some zero stuffing (silence) at the end of files, so I would get clicks when "looping" sounds. Dunno how it looks with ogg files.
Both objects are not really fit for doing DJish synchronization let alone beatmatching. For this, only readanysf~ comes close, however not close enough for my taste.
If I may ask: what do you mean "not close enough"? What you don't like about readanysf~?
cheers, Bart
Le 3 Février 2005 18:23, Bartlomiej Bazior a écrit :
Frank Barknecht :
There is an mp3play~ object in the IEMLib, also on CVS.
Yes, I know about that one - no "speed" control, though. But a moment ago it striked me, that using variable speed mp3 playing external will propably cause me a bigger problem. I was planning to use that kind of object to play various sound loops - my patch works more less like ableton Live, where I trigger those sounds by midi events. The patch has bpm control which controls the speed at which all the files are being played (that is why I asked about mp3 playing external). But now I remembered that mp3 encoders do some zero stuffing (silence) at the end of files, so I would get clicks when "looping" sounds. Dunno how it looks with ogg files.
Try AlsaPlayer with jack; it was discussed earlier on this list. There's an external to control AlsaPlayer, which can be told to play at different speed, even backward. For loop manipulation, sample the AlsaPlayer jack input in PD. -- Marc
Try AlsaPlayer with jack; it was discussed earlier on this list. There's an external to control AlsaPlayer, which can be told to play at different speed, even backward. For loop manipulation, sample the AlsaPlayer jack input in PD.
Given that alsaplayer and jack are linux programs, and readanysf~ runs on linux, what's the advantage for one or the other?
-- Marc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Given that alsaplayer and jack are linux programs, and readanysf~ runs on linux, what's the advantage for one or the other?
just thought I might jump in here.
there is no reason that the current readanysf~ should not compile under windoze. I just don't have access to a windows machine to do the compile. It would be great if someone could tackle this.
on another note, I started to rewrite the readanysf~ code. the goal for the new version are as follows: 1.) direct c++ code for pd. no more flext. 2.) read forwards and backwards 3.) no more stereo default...should read multiple channels 4.) nudge function for frank :) 5.) possibly libsndfile options for reading more raw formats
things to keep: 1.) varispeed play 2.) transparent interface between files on disk and files streamed via http 3.) multithreaded for smooth playback 4.) wav, aiff, mp3, flac playback
most of this I got done already over HannaKwanaMas break. The rest I can only hope to complete by end of 2005.....too many pressures being an adult and such.
best -august.
august wrote:
on another note, I started to rewrite the readanysf~ code. the goal for the new version are as follows: 1.) direct c++ code for pd. no more flext.
what are the advantages of such an approach ?
or rather, what are the big disadvantages of using flext ? i do not use it myself (since Gem has its own C++ framework and my rest is done in C), so my ideas of flext might be clouded. the only reason to not use it that is see, is an additional dependency. isn't it possible to link statically against flext, so the dependency would only exist at compile time ? or is the flext-api highly unstable (so that it is a pain to upgrade from one version of flext to the next ?)
mfg.btr.xs IOhannes
Hi, i think the main problem flext and readanysf~ might be the latter's dependance on a large number of external libraries, although i don't know which kind of clash that could cause. Naturally, i use flext for nearly everything and i have had no real problem compiling it in the last couple of months. I also think that the new build system should be easy to use but it may not be fit for the complex building involved with readanysf~. The last time i tried to build readanysf~ for Windows i had the impression that the problems are not caused by flext, but i didn't really understand the code - that's why i chose to write my own flext-based soundfile player (although i doesn't decode MP3, because i don't use crippled sound) It's true that flext has changed a bit in the last time, but not the API, just the naming of the libraries, so that it's uniform across several platforms. I think that should be trivial to adapt. The API itself hasn't changed for the last two years or so. It seems to be at least as stable as the pd API.
best greetings, Thomas
Am 04.02.2005 um 10:33 schrieb IOhannes m zmoelnig:
august wrote:
on another note, I started to rewrite the readanysf~ code. the goal for the new version are as follows: 1.) direct c++ code for pd. no more flext.
what are the advantages of such an approach ?
or rather, what are the big disadvantages of using flext ? i do not use it myself (since Gem has its own C++ framework and my rest is done in C), so my ideas of flext might be clouded. the only reason to not use it that is see, is an additional dependency. isn't it possible to link statically against flext, so the dependency would only exist at compile time ? or is the flext-api highly unstable (so that it is a pain to upgrade from one version of flext to the next ?)
mfg.btr.xs IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
i think the main problem flext and readanysf~ might be the latter's dependance on a large number of external libraries, although i don't know which kind of clash that could cause.
actually, the biggest problem for me at the moment is the object wrapping that exists in flext. now, whenever you delete() a C++ object using a flext version greater than 4.5, PD will crash hard. There is a switch in flext, but expecting users to turn this off is a bit too much.
what are the advantages of such an approach ?
or rather, what are the big disadvantages of using flext ?
well, initially, I thought it would be great to easily compile pd externals for MAX. but, the chances of me ever getting around to taking the time to sit in front of a macintosh or windows machine and compiling an external are now becoming more and more slim. and, if you are writing in C++ anyway, then you probably have your objects in a decent enough form to just switch from the pd api to the max api.
i do not use it myself (since Gem has its own C++ framework and my rest is done in C), so my ideas of flext might be clouded. the only reason to not use it that is see, is an additional dependency. isn't it possible to link statically against flext, so the dependency would only exist at compile time ?
you could link statically, but then it adds some uneeded KB (about 90kb I think) to your external. and if you load 20 of an external, this is a pretty heavy hit.
or is the flext-api highly unstable (so that it is a pain to upgrade from one version of flext to the next ?)
except for the changes from 0.4.5 to 0.4.6, flext has proven to be extremely stable.
and, like frank said, you will probably want flext anyway on your machine to get Thomas's awesome externals.
best -august.
actually, the biggest problem for me at the moment is the object wrapping that exists in flext. now, whenever you delete() a C++ object using a flext version greater than 4.5, PD will crash hard.
Oh wow, that's news to me, i do that many times in my externals (i try not to do it too often!). Maybe you could send me a short example? The only situation where i can imagine that this is happening, is when you use new() in source code without including flext headers and delete() the same memory in source code with included flext headers, or vice versa - this situation should be easily avoidable, though. This is because flext globally redefines new and delete to use PDs memory allocation functions.
all the best, Thomas
Le 4 Février 2005 11:05, august a écrit :
or rather, what are the big disadvantages of using flext ?
... and, if you are writing in C++ anyway, then you probably have your objects in a decent enough form to just switch from the pd api to the max api.
That's exactly what flext is meant to be: a decent enough object library for the creation of cross-platform externals for PD and Max . And we want to use it because of its community; I'm more interested to share with a larger group of casual and experienced developpers than to learn how to fiddle with a bunch of personal APIs. I'm not against the idea of rewriting an external made with flext, but if there's no major reason to replace flext, then it's better to use it. Free software needs legacy... -- Marc
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
or rather, what are the big disadvantages of using flext ? i do not use it myself (since Gem has its own C++ framework and my rest is done in C), so my ideas of flext might be clouded. the only reason to not use it that is see, is an additional dependency. isn't it possible to link statically against flext, so the dependency would only exist at compile time ? or is the flext-api highly unstable (so that it is a pain to upgrade from one version of flext to the next ?)
Being the author of some flext externals myself I'd say, that using flext can be a disadvantage for users trying to compile the externals. However the advantages in using flext for me as developer outweight that, IMO. It is really well documented, very clean, has lots of useful utility functions and I need to use flext anyways for Thomas' cool externals, so flext is already installed.
And I like libraries and code reuse in general, so why should there be a different C++ interface for externals in Gem, PDcontainers, readanysf~, creb, ...?
Ciao
Frank Barknecht _ ______footils.org__
august :
just thought I might jump in here.
there is no reason that the current readanysf~ should not compile under windoze. I just don't have access to a windows machine to do the compile. It would be great if someone could tackle this.
Ah. So there _is_ a little hope? ;-) I'll try to build it as soon as cygwin site will go online (I suppose that using microsoft compiler might not be a good idea in this case, right?).
cheers, Bart
august wrote:
Given that alsaplayer and jack are linux programs, and readanysf~ runs on linux, what's the advantage for one or the other?
just thought I might jump in here.
there is no reason that the current readanysf~ should not compile under windoze. I just don't have access to a windows machine to do the compile. It would be great if someone could tackle this.
on another note, I started to rewrite the readanysf~ code. the goal for the new version are as follows: 1.) direct c++ code for pd. no more flext. 2.) read forwards and backwards 3.) no more stereo default...should read multiple channels 4.) nudge function for frank :) 5.) possibly libsndfile options for reading more raw formats
things to keep: 1.) varispeed play 2.) transparent interface between files on disk and files streamed via http 3.) multithreaded for smooth playback 4.) wav, aiff, mp3, flac playback
most of this I got done already over HannaKwanaMas break. The rest I can only hope to complete by end of 2005.....too many pressures being an adult and such.
best -august.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
sounds great! best greetings, vincent
I read:
1.) direct c++ code for pd. no more flext. 2.) read forwards and backwards 3.) no more stereo default...should read multiple channels 4.) nudge function for frank :) 5.) possibly libsndfile options for reading more raw formats
how about
6.) cdda/libparanoia support ?
greetings,
x
Le 3 Février 2005 22:09, Ian Smith-Heisters a écrit :
Try AlsaPlayer with jack; it was discussed earlier on this list. There's an external to control AlsaPlayer, which can be told to play at different speed, even backward. For loop manipulation, sample the AlsaPlayer jack input in PD.
Given that alsaplayer and jack are linux programs, and readanysf~ runs on linux, what's the advantage for one or the other?
If it works as announced, readanyfs~ is an excellent choice, especially for loops. Using jack is only to get live input from other software. -- Marc
Marc Lavallée wrote:
Le 3 Février 2005 22:09, Ian Smith-Heisters a écrit :
Try AlsaPlayer with jack; it was discussed earlier on this list. There's an external to control AlsaPlayer, which can be told to play at different speed, even backward. For loop manipulation, sample the AlsaPlayer jack input in PD.
Given that alsaplayer and jack are linux programs, and readanysf~ runs on linux, what's the advantage for one or the other?
If it works as announced,
i can tell it does, except may be for random access to flac files (which is dependent on the developpement of the flac lib...)
vincent
readanyfs~ is an excellent choice, especially for loops. Using jack is only to get live input from other software. -- Marc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
august -
Bartlomiej Bazior -
CK -
Frank Barknecht -
Ian Smith-Heisters -
IOhannes m zmoelnig -
Marc Lavallée -
Max Neupert -
oliver -
Thomas Grill -
vincent rioux