Forums > MaxMSP

mdegranular~ on intel mac

May 24, 2007 | 5:21 pm

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

thanks


May 25, 2007 | 6:01 pm

>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

>thanks

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.

PB 1.25 GHz, 512 RAM 10.4.9


April 10, 2008 | 10:53 am

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

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


April 10, 2008 | 11:11 am


April 18, 2008 | 5:18 pm

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

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


April 18, 2008 | 5:42 pm



FP
April 18, 2008 | 8:07 pm

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



FP

April 22, 2008 | 6:58 am

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

Best,

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/


April 22, 2008 | 7:03 am

Hi Kim,

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

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

Thanks for the feedback Kim! Best,

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/


April 29, 2008 | 2:54 pm

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


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