roger.carruthers

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

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

Btw, is it me, or is the (new) forum search engine

not spectacularly good ? It seems to come up with a

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


mp3-playback-omx

In max/MSP, importing mp3 to a buffer~ is a decompilation process made 

within quicktime : it's damn slow on any computer.

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.

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

This is certainly an answer for the pluggo list... but. You'll find 

this information p. 59 in the "PluggoDevGuide35.pdf" documentation.

This is certainly an answer for the pluggo list... but. You'll find  
this information p. 59 in the "PluggoDevGuide35.pdf" documentation.

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

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

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.

Has this been patched in earlier releases?

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

> Has this been patched in earlier releases?

You should search the archives for explanation of bit resolutions and 

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 

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

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

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France

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 Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

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

-------------------------x---
--_____-----------|----------
--(_|_ ----|-----|-----()---
-- _|_)----|-----()----------
----------()------------x----

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


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.

If Max's %~ computation is absolutely correct,

the left one should be absolutely incorrect:

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

-- 
Jean-Yves Bernier
http://www.pescadoo.net/


> 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 

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.

mp3 playback & omx