chrishometaping

hi, does anybody know of a version of mdegranular that will run on an intel mac os x? i'm running max 4.6.1

mdegranular-on-intel-mac

>hi, does anybody know of a version of mdegranular that will run on >an intel mac os x? i'm running max 4.6.1

I am still on Max MSP 4.5.7 precisely for fear of losing mdegranular~. I remember reading that upgrading Max MSP would cause problems with 3rd party externals but that there was also a way of mitigating the problem.

I have a strong feeling that Max MSP 4.6 is a UB (universal binary) and all the externals need to be too (sorry chrishometaping). Can someone please confirm or deny this.

I am still on Max MSP 4.5.7 precisely for fear of losing mdegranular~.  I remember reading that upgrading Max MSP would cause problems with 3rd party externals but that there was also a way of mitigating the problem.

I have a strong feeling that Max MSP 4.6 is a UB (universal binary) and all the externals need to be too (sorry chrishometaping).  Can someone please confirm or deny this.

> is there a way to toggle the mdeGranular~ object reporting to the Max 

Do you mean, just turning it off, so it never posts there? No, there 

isn't at the moment. I could easily implement if of course but those 

messages usually indicated you're doing something wrong and the whole 

thing is about to go belly-up soon, as I think your next message 

Thanks, I've found it useful over the years. Still needs some poking 

Michael Edwards Tel. Office: (+44) (0)131 650 2431

Music Technology Email: michael.edwards@ed.ac.uk

MSc in Digital Composition and Performance

> is there a way to toggle the mdeGranular~ object reporting to the Max 
> window?

Do you mean, just turning it off, so it never posts there?  No, there 
isn't at the moment.  I could easily implement if of course but those 
messages usually indicated you're doing something wrong and the whole 
thing is about to go belly-up soon, as I think your next message 
indicates ;)

Thanks, I've found it useful over the years.  Still needs some poking 
though...

Michael Edwards                  Tel. Office: (+44) (0)131 650 2431
Music Technology                 Email: michael.edwards@ed.ac.uk
The University of Edinburgh
Programme Director
MSc in Digital Composition and Performance
http://www.ace.ed.ac.uk/Postgraduate/dcp
http://uofe.michael-edwards.org/


On Apr 10, 2008, at 3:53 AM, Michael Edwards wrote:

>> is there a way to toggle the mdeGranular~ object reporting to the 

> Do you mean, just turning it off, so it never posts there? No, 

> there isn't at the moment. I could easily implement if of course 

> but those messages usually indicated you're doing something wrong 

> and the whole thing is about to go belly-up soon, as I think your 

yes...but sometimes this is disruptive to seeing other messages sent 

by other externals and it would be nice to have the option of turning 

> Thanks, I've found it useful over the years. Still needs some 

> Michael Edwards Tel. Office: (+44) (0)131 650 2431

> Music Technology Email: michael.edwards@ed.ac.uk

> MSc in Digital Composition and Performance

> Hi Kim,
>
>> is there a way to toggle the mdeGranular~ object reporting to the  
>> Max window?
>
> Do you mean, just turning it off, so it never posts there?  No,  
> there isn't at the moment.  I could easily implement if of course  
> but those messages usually indicated you're doing something wrong  
> and the whole thing is about to go belly-up soon, as I think your  
> next message indicates ;)
yes...but sometimes this is disruptive to seeing other messages sent  
by other externals and it would be nice to have the option of turning  
it off
:)

>
>> nice external!
>
> Thanks, I've found it useful over the years.  Still needs some  
> poking though...
>
> Cheers,
>
> 	Michael
>
>
>
> Michael Edwards                  Tel. Office: (+44) (0)131 650 2431
> Music Technology                 Email: michael.edwards@ed.ac.uk
> The University of Edinburgh
> Programme Director
> MSc in Digital Composition and Performance
> http://www.ace.ed.ac.uk/Postgraduate/dcp
> http://uofe.michael-edwards.org/


mdegranular is working here.
os10.4.11, macbookpro intel, max4.6.3


http://ddm.caad.ed.ac.uk/staff/michael/software/mdegranular/mdeGranular.zip

here's the link: http://ddm.caad.ed.ac.uk/staff/michael/software/mdegranular/mdeGranular.zip


>> Do you mean, just turning it off, so it never posts there? No, there 

>> isn't at the moment. I could easily implement if of course but those 

>> messages usually indicated you're doing something wrong and the whole 

>> thing is about to go belly-up soon, as I think your next message 

> yes...but sometimes this is disruptive to seeing other messages sent by 

> other externals and it would be nice to have the option of turning it off

I understand your point of view but the thing to do is to avoid 

triggering the conditions that cause the error messages. I've 

reluctantly added this feature to my todo list though ;)

>> Do you mean, just turning it off, so it never posts there?  No, there 
>> isn't at the moment.  I could easily implement if of course but those 
>> messages usually indicated you're doing something wrong and the whole 
>> thing is about to go belly-up soon, as I think your next message 
>> indicates ;)
> yes...but sometimes this is disruptive to seeing other messages sent by 
> other externals and it would be nice to have the option of turning it off
> :)

I understand your point of view but the thing to do is to avoid 
triggering the conditions that cause the error messages.  I've 
reluctantly added this feature to my todo list though ;)

>> Uhuh, I'm with you up to there. The message makes sense though 

>> because whether you're granulating a static buffer~ or live incoming 

>> sound, mdeGranular has an internal buffer to hold live samples and the 

>> default size for that is 1000ms. So you can't just say 'set ms5000' 

>> before setting MaxLiveBufferMS to something larger.

> ah OK I see...what is confusing is which buffer is being reported as not 

> being large enough...i.e. the buffer~ object or the MaxLiveBufferMS 

> which I assume is the mdeGranular buffer

It's the mdeGranular~ buffer. I'll try to make that more clear in my 

>> MaxLiveBufferMS is there to allocate the maximum amount of memory 

>> you'll need in your performance (you should probably do it at 

>> startup), after which you do 'set ms500' or whatever, to restrict the 

>> amount of that memory you're actually going to use for granulation. 

>> This means we can avoid huge memory allocations as the performance is 

>> running (expensive on system resources).

> OK...not sure that I've ever encountered this feature elsewhere in 

> Max/MSP i.e. having to manage two separate buffers when using an MSP object

> if the audio data in the buffer~ object is being indexed/granulated by 

> mdeGranulator I guess I'm not clear on why there needs to be two audio 

Because you either do granulation of a static buffer~ that you manage 

yourself, or you granulate an incoming signal. For that we need an 

internal buffer. Handling the read/write pointer is by no means trivial 

and I didn't want to leave that to the user (otherwise what's the point 

> groove~ points to a buffer~ object without having to set internal 

> and sfplay~ has an internal buffer which allows you to set the size (via 

> it would seem less confusing if you let mdeGran internal buffer 

> auto-size to the buffer~ being indexed?

> ...or am I completely off base about this?

Yes, there's a misunderstanding. If you're indexing a buffer~ then my 

object doesn't buffer anything itself; it's only using its internal 

>> My experience is, once you've allocated your memory via 

>> MaxLiveBufferMS you should be able to flip backwards and forwards 

>> between live signal and buffer~ processing without a problem (I've 

>> been doing it in performance for the last five years, but mainly on PC 

>> I admit). The only thing to watch out for is the clicks which may 

>> occur when you switch (shouldn't worry you though, glitchy Kim ;)

>> And I should add, I haven't yet put the object through its paces on 

>> MacIntel so can't really vouch for it there. So, give it a hammering 

> I'm afraid I'm not on MacIntel -- still grinding away happily on my 

It should be OK on a G4; I've done several concerts on that.

>> Uhuh, I'm with you up to there.  The message makes sense though 
>> because whether you're granulating a static buffer~ or live incoming 
>> sound, mdeGranular has an internal buffer to hold live samples and the 
>> default size for that is 1000ms.  So you can't just say 'set ms5000' 
>> before setting MaxLiveBufferMS to something larger.
> ah OK I see...what is confusing is which buffer is being reported as not 
> being large enough...i.e. the buffer~ object or the MaxLiveBufferMS 
> which I assume is the mdeGranular buffer

It's the mdeGranular~ buffer.  I'll try to make that more clear in my 
warning messages.

>> MaxLiveBufferMS is there to allocate the maximum amount of memory 
>> you'll need in your performance (you should probably do it at 
>> startup), after which you do 'set ms500' or whatever, to restrict the 
>> amount of that memory you're actually going to use for granulation.  
>> This means we can avoid huge memory allocations as the performance is 
>> running (expensive on system resources).
> OK...not sure that I've ever encountered this feature elsewhere in 
> Max/MSP i.e. having to manage two separate buffers when using an MSP object
> if the audio data in the buffer~ object is being indexed/granulated by 
> mdeGranulator I guess I'm not clear on why there needs to be two audio 
> buffers to manage?

Because you either do granulation of a static buffer~ that you manage 
yourself, or you granulate an incoming signal.  For that we need an 
internal buffer.  Handling the read/write pointer is by no means trivial 
and I didn't want to leave that to the user (otherwise what's the point 
of them using my object?).

> groove~ points to a buffer~ object without having to set internal 
> buffers in groove~
> and sfplay~ has an internal buffer which allows you to set the size (via 
> the second arg)
> it would seem less confusing if you let mdeGran internal buffer 
> auto-size to the buffer~ being indexed?
> ...or am I completely off base about this?

Yes, there's a misunderstanding.  If you're indexing a buffer~ then my 
object doesn't buffer anything itself; it's only using its internal 
buffer when granulating a 'live' signal.

>> My experience is, once you've allocated your memory via 
>> MaxLiveBufferMS  you should be able to flip backwards and forwards 
>> between live signal and buffer~ processing without a problem (I've 
>> been doing it in performance for the last five years, but mainly on PC 
>> I admit).  The only thing to watch out for is the clicks which may 
>> occur when you switch (shouldn't worry you though, glitchy Kim ;)
>>
>> And I should add, I haven't yet put the object through its paces on 
>> MacIntel so can't really vouch for it there.  So, give it a hammering 
>> and let me know.
> I'm afraid I'm not on MacIntel -- still grinding away happily on my 
> Powerbook G4

On Apr 22, 2008, at 12:03 AM, Michael Edwards wrote:

> Because you either do granulation of a static buffer~ that you 

> manage yourself, or you granulate an incoming signal. For that we 

> need an internal buffer. Handling the read/write pointer is by no 

> means trivial and I didn't want to leave that to the user 

> (otherwise what's the point of them using my object?).

got it...this needs to be made more clear in the help file...I see 

the logic in having the internal/external buffers for granular

but IMHO most people will pr0lly end up using the internal buffer not 

while special cases will end up using an external buffer so they can 

so maybe make using the internal the default mode while using the 

>> groove~ points to a buffer~ object without having to set internal 

>> and sfplay~ has an internal buffer which allows you to set the 

>> it would seem less confusing if you let mdeGran internal buffer 

>> auto-size to the buffer~ being indexed?

>> ...or am I completely off base about this?

> Yes, there's a misunderstanding. If you're indexing a buffer~ then 

> my object doesn't buffer anything itself; it's only using its 

> internal buffer when granulating a 'live' signal.

I grok this now -- thanks for clearing that up...could the internal 

mdeGranular~ buffer have an 'auto size' message like some of the 

> Because you either do granulation of a static buffer~ that you  
> manage yourself, or you granulate an incoming signal.  For that we  
> need an internal buffer.  Handling the read/write pointer is by no  
> means trivial and I didn't want to leave that to the user  
> (otherwise what's the point of them using my object?).
got it...this needs to be made more clear in the help file...I see  
the logic in having the internal/external buffers for granular
but IMHO most people will pr0lly end up using the internal buffer not  
wanting to mess with pointer arithmetic
while special cases will end up using an external buffer so they can  
manage the pointer themselves
so maybe make using the internal the default mode while using the  
external a power-user mode?
just a thought...

>
>> groove~ points to a buffer~ object without having to set internal  
>> buffers in groove~
>> and sfplay~ has an internal buffer which allows you to set the  
>> size (via the second arg)
>> it would seem less confusing if you let mdeGran internal buffer  
>> auto-size to the buffer~ being indexed?
>> ...or am I completely off base about this?
>
> Yes, there's a misunderstanding.  If you're indexing a buffer~ then  
> my object doesn't buffer anything itself; it's only using its  
> internal buffer when granulating a 'live' signal.
I grok this now -- thanks for clearing that up...could the internal  
mdeGranular~ buffer have an 'auto size' message like some of the  
other MSP objects?


mdegranular~ on intel mac