mp3 playback & omx

Jan 20, 2006 at 10:04am

mp3 playback & omx

I’m putting together a Max based radio playout system
for someone, and I have a couple of questions:

First mp3 playback in Max/MSP; importing mp3′s into a
buffer~ seems really slow on my G4 867 – is this just
cos it’s a fairly slow machine by today’s standards ?
Can anyone comment on the use of mp3 playout systems
using buffers~ in, say, live situations ? Fast enough
?

The other alternative, using spigot~, I know is broke
in QT7, but am I right in thinking that under OSX/XP,
spigot~ can only grab from jit.qt.movie, so even
if/when it does get fixed, it would only work if I had
Jitter anyway ?

With regards the Octimax stuff, what are the licensing
restrictions on using these objects in standalones -
I’m guessing that if they’re not OK to use in Pluggo’s
then distributing them in standalones is a no-no too,
but I couldn’t find any info about this either in the
docs or by searching the forum.
Btw, is it me, or is the (new) forum search engine
not spectacularly good ? It seems to come up with a
lot of zeros,
cheers
Roger

#24005
Jan 20, 2006 at 10:20am

In max/MSP, importing mp3 to a buffer~ is a decompilation process made
within quicktime : it’s damn slow on any computer.
No solutions, i guess.

best

f.e

#68756
Jan 20, 2006 at 10:20am

Hi,

I don’t have an answer to your question and this is quite off topic, but I was wondering: where do you get the info that some objects (like optimax) are not legal to distribute as Pluggo standalones ? I searched the site but couldn’t find it…

Regards,
amo

#68757
Jan 20, 2006 at 10:31am

Hi,

This is certainly an answer for the pluggo list… but. You’ll find
this information p. 59 in the “PluggoDevGuide35.pdf” documentation.

HTH,
ej

#68758
Jan 20, 2006 at 10:38am

Thanls for the info.
Best,
amo

#68759
Jan 20, 2006 at 10:39am

>> I don’t have an answer to your question and this is quite off
>> topic, but I was wondering: where do you get the info that some
>> objects (like optimax) are not legal to distribute as Pluggo
>> standalones ? I searched the site but couldn’t find it…

They won’t instantiate in a pluggo. Might be that they will if the
pluggo is used in MaxMSP using vst~ (I don’t recall), but once you
try using it in another audio editor, it won’t work.

Best,
Trond

#68760
Jan 20, 2006 at 8:28pm

The following patch shows that %~ computes incorrectly N%N and 2*N/N.

For example: 10%~10 = 10, 10%~20= 10, 10%~30 and higher = 0.

I use Max/MSP 4.1.

Has this been patched in earlier releases?

max v2;
#N vpatcher 747 435 1147 735;
#P number 153 199 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 153 148 27 196617 %;
#P newex 73 104 27 196617 sig~;
#P number 170 52 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 73 52 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 271 150 27 196617 stop;
#P message 257 132 65 196617 startwindow;
#P newex 282 185 29 196617 dac~;
#P user number~ 73 200 112 215 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 222 222 222
222 222 222 0 0 0;
#P newex 73 147 27 196617 %~;
#B color 5;
#P connect 5 0 7 0;
#P connect 7 0 0 0;
#P connect 0 0 1 0;
#P connect 6 0 0 1;
#P connect 5 0 8 0;
#P connect 8 0 9 0;
#P connect 6 0 8 1;
#P fasten 3 0 2 0 262 179 287 179;
#P fasten 4 0 2 0 276 179 287 179;
#P pop;

#68761
Jan 25, 2006 at 9:26pm

Jean-Yves Bernier wrote:
> The following patch shows that %~ computes incorrectly N%N and 2*N/N.
>
> For example: 10%~10 = 10, 10%~20= 10, 10%~30 and higher = 0.
>
> I use Max/MSP 4.1.
>
> Has this been patched in earlier releases?

You should search the archives for explanation of bit resolutions and
alike.
Max computes absolutely correct, as in signal land everything is
floating point. At the border of the range you are close enough to being
either almost a multiple of ten or just a tiny little bit more. The one
would show 10. the other 0.
Floats aren’t just as obvious as ints…

Stefan

[][] [][][] [][] [][][] [][] [][][] [][] [][][]
[][][][][][][][][][][][][][][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

————————-x—
–_____———–|———-
–(_|_ —-|—–|—–()—
– _|_)—-|—–()———-
———-()————x—-

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France
Phone at CCMIX +33-1-49 77 51 72

#68762
Jan 27, 2006 at 12:27am

At 22:26 +0100 25/01/2006, Stefan Tiedje wrote:

>At the border of the range you are close enough to being
>either almost a multiple of ten or just a tiny little bit more.
>The one would show 10. the other 0.

If Max’s %~ computation is absolutely correct,
the left one should be absolutely incorrect:

max v2;
#N vpatcher 575 292 1069 747;
#N vpreset 4;
#X append 1 2 5 37 215 flonum float 10. ; 6 275 73 number~ list 0. 0. ; 8
275 261 number~ list 0. 0. ; 10 37 90 flonum float 10. ;;
#X append 2 2 5 37 215 flonum float 10. ; 6 275 73 number~ list 0. 0. ; 8
275 261 number~ list 0. 0. ; 10 37 90 flonum float 20. ;;
#X append 3 2 5 37 215 flonum float 10. ; 6 275 73 number~ list 0. 0. ; 8
275 261 number~ list 0. 0. ; 10 37 90 flonum float 30. ;;
#X append 4 2 5 37 215 flonum float 10. ; 6 275 73 number~ list 0. 0. ; 8
275 261 number~ list 0. 0. ; 10 37 90 flonum float 40. ;;
#P preset 331 71 47 27;
#P flonum 90 37 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user ezdac~ 389 195 433 228 0;
#P user number~ 261 275 300 290 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 222 222 222
222 222 222 0 0 0;
#P newex 261 198 27 196617 %~;
#P user number~ 73 275 112 290 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 222 222 222
222 222 222 0 0 0;
#P flonum 215 37 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 90 79 27 196617 sig~;
#P newex 90 197 54 196617 *~;
#P newex 90 171 38 196617 trunc~;
#P newex 90 144 27 196617 /~;
#P newex 73 232 27 196617 -~;
#P fasten 4 0 0 0 95 134 78 134;
#P connect 0 0 6 0;
#P connect 10 0 4 0;
#P connect 4 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 0 1;
#P fasten 5 0 1 1 220 124 112 124;
#P lcolor 15;
#P fasten 5 0 3 1 220 124 139 124;
#P lcolor 15;
#P fasten 4 0 7 0 95 106 266 106;
#P connect 7 0 8 0;
#P fasten 5 0 7 1 220 124 283 124;
#P lcolor 15;
#P pop;


Jean-Yves Bernier

http://www.pescadoo.net/

#68763
Jan 27, 2006 at 12:23pm

Jean-Yves Bernier wrote:
> If Max’s %~ computation is absolutely correct,
> the left one should be absolutely incorrect:

Yes, the left one is less precise, you have to make the result
numberboxes a bit bigger, set the right to 10.31 for example and you’ll
see sometimes a difference in the last digit.

And there is no absolutation for correctness in floating point… ;-)
Both solutions are correct in a certain sense, but they don’t have the
same precision.

Stefan

[][] [][][] [][] [][][] [][] [][][] [][] [][][]
[][][][][][][][][][][][][][][][][][][][][][][][][][][][]

Stefan Tiedje
Klanggestalter
Electronic Composition
&
Improvisation

/~~~~~
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
___/ ///

————————-x—
–_____———–|———-
–(_|_ —-|—–|—–()—
– _|_)—-|—–()———-
———-()————x—-

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France
Phone at CCMIX +33-1-49 77 51 72

#68764

You must be logged in to reply to this topic.