davidestevens

At the risk of appearing totally dumb ...

I'm going to be using my G4 powerbook for the foreseeable future. Ie 

I use quite a lot of 3rd part objects. (I read the messages about 

plugins, but it's Objects I'm concerned about).

If I update to 4.6, will I still be able to use _all_ my 3rd party 

stuff as is, or do the objects need to be modified to work with the 

I'm going to be using my G4 powerbook for the foreseeable future. Ie  
non-Intel.
I use quite a lot of 3rd part objects. (I read the messages about  
plugins, but it's Objects I'm concerned about).

If I update to 4.6, will I still be able to use _all_ my 3rd party  
stuff as is, or do the objects need to be modified to work with the  
new version of max on a PPC mac?

4-6-and-3rd-party-objects

in theory, the answer should be yes, if you install CFM support, and 

if the objects are 'max' objects, not jitter objects.

in reality it seems like there might be some issues. Considering 4.6 

and 4.5.7 can live side by side (as each has its own Cycling 74 

support folder) if you dont mungle your search paths, you could test.

On Aug 22, 2006, at 2:54 PM, David Stevens wrote:

> At the risk of appearing totally dumb ...

> I'm going to be using my G4 powerbook for the foreseeable future. 

> I use quite a lot of 3rd part objects. (I read the messages about 

> plugins, but it's Objects I'm concerned about).

> If I update to 4.6, will I still be able to use _all_ my 3rd party 

> stuff as is, or do the objects need to be modified to work with the 

in theory, the answer should be yes, if you install CFM support, and  
if the objects are 'max' objects, not jitter objects.

in reality it seems like there might be some issues. Considering 4.6  
and 4.5.7 can live side by side (as each has its own Cycling 74  
support folder) if you dont mungle your search paths, you could test.

> At the risk of appearing totally dumb ...
>
> I'm going to be using my G4 powerbook for the foreseeable future.  
> Ie non-Intel.
> I use quite a lot of 3rd part objects. (I read the messages about  
> plugins, but it's Objects I'm concerned about).
>
> If I update to 4.6, will I still be able to use _all_ my 3rd party  
> stuff as is, or do the objects need to be modified to work with the  
> new version of max on a PPC mac?
>
> OK - off to put on my dunces cap.
>
> ta
>
> David
>

OK - and CFM support is something that comes with 4.6?? (Sorry, but I 

> in theory, the answer should be yes, if you install CFM support, 

> and if the objects are 'max' objects, not jitter objects.

> in reality it seems like there might be some issues. Considering 

> 4.6 and 4.5.7 can live side by side (as each has its own Cycling 74 

> support folder) if you dont mungle your search paths, you could test.

> On Aug 22, 2006, at 2:54 PM, David Stevens wrote:

>> At the risk of appearing totally dumb ...

>> I'm going to be using my G4 powerbook for the foreseeable future. 

>> I use quite a lot of 3rd part objects. (I read the messages about 

>> plugins, but it's Objects I'm concerned about).

>> If I update to 4.6, will I still be able to use _all_ my 3rd party 

>> stuff as is, or do the objects need to be modified to work with 

OK - and CFM support is something that comes with 4.6?? (Sorry, but I  
have no idea what CFM is!)

> in theory, the answer should be yes, if you install CFM support,  
> and if the objects are 'max' objects, not jitter objects.
>
> in reality it seems like there might be some issues. Considering  
> 4.6 and 4.5.7 can live side by side (as each has its own Cycling 74  
> support folder) if you dont mungle your search paths, you could test.
>
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
> On Aug 22, 2006, at 2:54 PM, David Stevens wrote:
>
>> At the risk of appearing totally dumb ...
>>
>> I'm going to be using my G4 powerbook for the foreseeable future.  
>> Ie non-Intel.
>> I use quite a lot of 3rd part objects. (I read the messages about  
>> plugins, but it's Objects I'm concerned about).
>>
>> If I update to 4.6, will I still be able to use _all_ my 3rd party  
>> stuff as is, or do the objects need to be modified to work with  
>> the new version of max on a PPC mac?
>>
>> OK - off to put on my dunces cap.
>>
>> ta
>>
>> David
>>
>

No worries. Cycling updated how externals are made with the SDK kit, 

and they now use XCode, rather than CodeWarrior. Also, externals can 

now be Universal Binary, and typically are .mxo files. These mxo 

files are compiled as a different executable format (I believe its 

mach-o). CFM externals were created with Codewarrior, for older 

For 4.6 to support the old 'CFM' (ie codewarrior, non universal 

binary code), Cycling has provided with a 'shunt' library that lets 

Max load the old type of externals. Included in 4.6 is a changelog 

On Aug 22, 2006, at 3:32 PM, David Stevens wrote:

> OK - and CFM support is something that comes with 4.6?? (Sorry, but 

>> in theory, the answer should be yes, if you install CFM support, 

>> and if the objects are 'max' objects, not jitter objects.

>> in reality it seems like there might be some issues. Considering 

>> 4.6 and 4.5.7 can live side by side (as each has its own Cycling 

>> 74 support folder) if you dont mungle your search paths, you could 

>> On Aug 22, 2006, at 2:54 PM, David Stevens wrote:

>>> At the risk of appearing totally dumb ...

>>> I'm going to be using my G4 powerbook for the foreseeable future. 

>>> I use quite a lot of 3rd part objects. (I read the messages about 

>>> plugins, but it's Objects I'm concerned about).

>>> If I update to 4.6, will I still be able to use _all_ my 3rd 

>>> party stuff as is, or do the objects need to be modified to work 

>>> with the new version of max on a PPC mac?

No worries.  Cycling updated how externals are made with the SDK kit,  
and they now use XCode, rather than CodeWarrior. Also, externals can  
now be Universal Binary, and typically are .mxo files. These mxo  
files are compiled as a different executable format (I believe its  
mach-o). CFM externals were created with Codewarrior, for older  
versions of Max.

For 4.6 to support the old 'CFM' (ie codewarrior, non universal  
binary code), Cycling has provided with a 'shunt' library that lets  
Max load the old type of externals. Included in 4.6 is a changelog  
that documents what is supported.

> OK - and CFM support is something that comes with 4.6?? (Sorry, but  
> I have no idea what CFM is!)
>
> thanks
>
> David
>
> On 22 Aug 2006, at 20:11, vade wrote:
>
>> in theory, the answer should be yes, if you install CFM support,  
>> and if the objects are 'max' objects, not jitter objects.
>>
>> in reality it seems like there might be some issues. Considering  
>> 4.6 and 4.5.7 can live side by side (as each has its own Cycling  
>> 74 support folder) if you dont mungle your search paths, you could  
>> test.
>>
>>
>> v a d e //
>>
>> www.vade.info
>> abstrakt.vade.info
>>
>>
>> On Aug 22, 2006, at 2:54 PM, David Stevens wrote:
>>
>>> At the risk of appearing totally dumb ...
>>>
>>> I'm going to be using my G4 powerbook for the foreseeable future.  
>>> Ie non-Intel.
>>> I use quite a lot of 3rd part objects. (I read the messages about  
>>> plugins, but it's Objects I'm concerned about).
>>>
>>> If I update to 4.6, will I still be able to use _all_ my 3rd  
>>> party stuff as is, or do the objects need to be modified to work  
>>> with the new version of max on a PPC mac?
>>>
>>> OK - off to put on my dunces cap.
>>>
>>> ta
>>>
>>> David
>>>
>>
>

Phew. One day we'll look back at all this and laugh!! Ha Ha!! How 

complex it all seemed. How confusing! Oh how we'll laugh ...

thanks, vade, I'll give it a go sometime this week ...

> For 4.6 to support the old 'CFM' (ie codewarrior, non universal 

> binary code), Cycling has provided with a 'shunt' library that lets 

> Max load the old type of externals. Included in 4.6 is a changelog 

> Aug 22, 2006, at 3:32 PM, David Stevens wrote:

>> OK - and CFM support is something that comes with 4.6?? (Sorry, 

Phew. One day we'll look back at all this and laugh!!  Ha Ha!!  How  
complex it all seemed. How confusing! Oh how we'll laugh ...

>
> For 4.6 to support the old 'CFM' (ie codewarrior, non universal  
> binary code), Cycling has provided with a 'shunt' library that lets  
> Max load the old type of externals. Included in 4.6 is a changelog  
> that documents what is supported.
>
>

>  Aug 22, 2006, at 3:32 PM, David Stevens wrote:
>
>
>> OK - and CFM support is something that comes with 4.6?? (Sorry,  
>> but I have no idea what CFM is!)
>>
>>


> No worries. Cycling updated how externals are made with the SDK 

> kit, and they now use XCode, rather than CodeWarrior. Also, 

> externals can now be Universal Binary, and typically are .mxo 

> files. These mxo files are compiled as a different executable 

> format (I believe its mach-o). CFM externals were created with 

> Codewarrior, for older versions of Max.

CodeWarrior is perfectly capable of producing Mach-O code, in fact 

many developers consider it the superior tool for this task. What it 

can't do is produce code for Intel-based Macs. The irony is that CW 

produces perfectly good Intel code for Windows. Apple's industrial 

politics not only made strange bedfellows but estranged bedfellows. 

Metrowerks makes CodeWarrior, and Metrowerks was bought up by 

Motorola years ago, so when Jobs dumped Motorola for Intel, there 

were repercussions (among them, Motorola has now sold off the entire 

Codewarrior line, in part to Nokia and in part to a .

CFM is the Code Fragment Manager, which was a system Mac OS used to <> manage code fragments, introduced around System 7.5 for the 

transition from the original 68000 family of processors to the PPC 

family. It was the technology that allowed developers to mix-and- 

match 68k and PPC code in the same application. It is still supported 

by OS X as an architecture for managing independent libraries of code 

that interact with each other (for example, Max/MSP plust jitlib plus 

myriads of external objects). However, Apple has wanted developers to 

move from CFM to the Mach-O architecture for at least as long as OS X 

has been out. So XCode was designed not to produce CFM code, and 

XCode is the only option for producing code for Intel-based Macs.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 22-Aug-2006, at 21:52, vade wrote:
> No worries.  Cycling updated how externals are made with the SDK  
> kit, and they now use XCode, rather than CodeWarrior. Also,  
> externals can now be Universal Binary, and typically are .mxo  
> files. These mxo files are compiled as a different executable  
> format (I believe its mach-o). CFM externals were created with  
> Codewarrior, for older versions of Max.
>
> For 4.6 to support the old 'CFM' (ie codewarrior, non universal  
> binary code), Cycling has provided with a 'shunt' library that lets  
> Max load the old type of externals. Included in 4.6 is a changelog  
> that documents what is supported.

CodeWarrior is perfectly capable of producing Mach-O code, in fact  
many developers consider it the superior tool for this task. What it  
can't do is produce code for Intel-based Macs. The irony is that CW  
produces perfectly good Intel code for Windows. Apple's industrial  
politics not only made strange bedfellows but estranged bedfellows.  
Metrowerks makes CodeWarrior, and Metrowerks was bought up by  
Motorola years ago, so when Jobs dumped Motorola for Intel, there  
were repercussions (among them, Motorola has now sold off the entire  
Codewarrior line, in part to Nokia and in part to a .

CFM is the Code Fragment Manager, which was a system Mac OS used to  <> manage code fragments, introduced around System 7.5 for the  
transition from the original 68000 family of processors to the PPC  
family. It was the technology that allowed developers to mix-and- 
match 68k and PPC code in the same application. It is still supported  
by OS X as an architecture for managing independent libraries of code  
that interact with each other (for example, Max/MSP plust jitlib plus  
myriads of external objects). However, Apple has wanted developers to  
move from CFM to the Mach-O architecture for at least as long as OS X  
has been out. So XCode was designed not to produce CFM code, and  
XCode is the only option for producing code for Intel-based Macs.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

4.6 and 3rd party objects?