Forums > MaxMSP

mp3 playback & omx

January 20, 2006 | 10:04 am

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



f.e
January 20, 2006 | 10:20 am

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



amo
January 20, 2006 | 10:20 am

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


January 20, 2006 | 10:31 am

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



amo
January 20, 2006 | 10:38 am

Thanls for the info.
Best,
amo


January 20, 2006 | 10:39 am

>> 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


January 20, 2006 | 8:28 pm

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;


January 25, 2006 | 9:26 pm

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


January 27, 2006 | 12:27 am

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/


January 27, 2006 | 12:23 pm

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


Viewing 10 posts - 1 through 10 (of 10 total)