mdegranular~ on intel mac

May 24, 2007 at 5:21pm

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

thanks

#32080
May 25, 2007 at 6:01pm

>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

#105029
Apr 10, 2008 at 10:53am

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/

#105030
Apr 10, 2008 at 11:11am

#105031
Apr 18, 2008 at 5:18pm

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/

#105032
Apr 18, 2008 at 5:42pm

#105033
Apr 18, 2008 at 8:07pm

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

#105034
Apr 18, 2008 at 8:10pm
#105035
Apr 22, 2008 at 6:58am

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

#105036
Apr 22, 2008 at 7:03am

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/

#105037
Apr 29, 2008 at 2:54pm

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?

#105038

You must be logged in to reply to this topic.