Anthony Palomba

As soon as the new Max5 SDK comes out, I would like to begin 

work on a new track object. There are two strategies I am 

looking at: A monolithic object that allows you to add tracks

internally to the object and edit all tracks within

that object. Or a track object that is a seperate element

that the user can add to a patch as they choose. In both cases, 

you have to worry about storing data. How will the Max5

SDK handle storing data of externals? I would be curious to

hear peoples feedback on which strategy they would implement.

I have been looking at an opensource sequencer called Rosegarden 

(www.rosegardenmusic.com). I am looking at maybe trying to port

as much of it as possible to Max. This might be a considerable 

amount of work depending on what graphics API the new SDK has.

But might be achievable. What do you guys think?

As soon as the new Max5 SDK comes out, I would like to begin 
work on a new track object. There are two strategies I am 
looking at: A monolithic object that allows you to add tracks
internally to the object and edit all tracks within
that object. Or a track object that is a seperate element
that the user can add to a patch as they choose. In both cases, 
you have to worry about storing data. How will the Max5
SDK handle storing data of externals? I would be curious to
hear peoples feedback on which strategy they would implement.

I have been looking at an opensource sequencer called Rosegarden 
(www.rosegardenmusic.com). I am looking at maybe trying to port
as much of it as possible to Max. This might be a considerable 
amount of work depending on what graphics API the new SDK has.
But might be achievable. What do you guys think?


developing-custom-track-external

I think you get a pretty clear idea of the graphics API in Max5 app (on the Mac at least, not sure if these would be installed on Windows):

/Applications/Max5/MaxMSP.app/Contents/Frameworks/MaxAPI.framework/Versions/A/Headers/jgraphics.h

...although it's not clear how exactly it is to be used. But you do have all the line/shape/path drawing stuff you might expect.

I've been looking at Juce for a while now (for other projects) and although its API isn't exposed directly inside the Max5 API I have tested linking Juce in an Max external for Max 5 and this seems to work for non-GUI stuff. (Even though Max uses Juce 1.45 and I'm using the current development version 1.46+.) No idea how/if the Juce GUI/Component classes can be used. In Juce (completely separate to Max) I pretty quickly made the basics of an audio waveform editor:

http://miajo.co.uk/downloads/audioeddie.jpg

..and a breakpoint envelope editor which needed significantly fewer lines of code than the ejies ej.function.js (broadly because all the mousing code is already dealt with).

Anyway gong a little off topic here...so coming back to your topic:

Juce also has some other neat classes, one for storing/retrieving data in XML which can be easily saved to disk or kept in memory etc. Then again I'm not sure if this:

/Applications/Max5/MaxMSP.app/Contents/Frameworks/MaxAPI.framework/Versions/A/Headers/ext_xmltree.h

...is new to the MaxAPI (I've kept away from MaxAPI dev since Max 5 appeared on the horizon).

(The code for this is at http://audioeddie.googlecom.com)

...is new to the MaxAPI (I've kept away from MaxAPI dev since Max 5 appeared on the horizon).


While Max 5 is indeed built using JUCE, we are not exporting or 

supporting any direct JUCE calls. If you want to use JUCE for 

something, then you will need to compile your own JUCE library and 

take care of everything related to it yourself.

The graphics API that we have created and export for use in externals, 

while drawn with JUCE underneath, is a separate layer of functions 

http://en.wikipedia.org/wiki/Cairo_%28graphics%29

If you are hoping to do some recreational reading prior to the Max 5 

SDK, reading about Cairo will prepare you for how things work.

Tap.Tools - Objects for Max, MSP, and Jitter

On 2008 May 22, at 1:48 AM, Martin Robinson wrote:

> I think you get a pretty clear idea of the graphics API in Max5 app 

> (on the Mac at least, not sure if these would be installed on 

> /Applications/Max5/MaxMSP.app/Contents/Frameworks/MaxAPI.framework/ 

> ...although it's not clear how exactly it is to be used. But you do 

> have all the line/shape/path drawing stuff you might expect.

> I've been looking at Juce for a while now (for other projects) and 

> although its API isn't exposed directly inside the Max5 API I have 

> tested linking Juce in an Max external for Max 5 and this seems to 

> work for non-GUI stuff. (Even though Max uses Juce 1.45 and I'm 

> using the current development version 1.46+.) No idea how/if the 

> Juce GUI/Component classes can be used. In Juce (completely separate 

> to Max) I pretty quickly made the basics of an audio waveform editor:

> ..and a breakpoint envelope editor which needed significantly fewer 

> lines of code than the ejies ej.function.js (broadly because all the 

> Anyway gong a little off topic here...so coming back to your topic:

> Juce also has some other neat classes, one for storing/retrieving 

> data in XML which can be easily saved to disk or kept in memory etc. 

> ...is new to the MaxAPI (I've kept away from MaxAPI dev since Max 5 

While Max 5 is indeed built using JUCE, we are not exporting or  
supporting any direct JUCE calls.  If you want to use JUCE for  
something, then you will need to compile your own JUCE library and  
take care of everything related to it yourself.

The graphics API that we have created and export for use in externals,  
while drawn with JUCE underneath, is a separate layer of functions  
based on Cairo:
	http://en.wikipedia.org/wiki/Cairo_%28graphics%29

If you are hoping to do some recreational reading prior to the Max 5  
SDK, reading about Cairo will prepare you for how things work.

____________________________________
Tap.Tools - Objects for Max, MSP, and Jitter
http://electrotap.com/taptoolsmax/

>
> I think you get a pretty clear idea of the graphics API in Max5 app  
> (on the Mac at least, not sure if these would be installed on  
> Windows):
>
> /Applications/Max5/MaxMSP.app/Contents/Frameworks/MaxAPI.framework/ 
> Versions/A/Headers/jgraphics.h
>
> ...although it's not clear how exactly it is to be used. But you do  
> have all the line/shape/path drawing stuff you might expect.
>
> I've been looking at Juce for a while now (for other projects) and  
> although its API isn't exposed directly inside the Max5 API I have  
> tested linking Juce in an Max external for Max 5 and this seems to  
> work for non-GUI stuff. (Even though Max uses Juce 1.45 and I'm  
> using the current development version 1.46+.) No idea how/if the  
> Juce GUI/Component classes can be used. In Juce (completely separate  
> to Max) I pretty quickly made the basics of an audio waveform editor:
>
> http://miajo.co.uk/downloads/audioeddie.jpg
>
> (The code for this is at http://audioeddie.googlecom.com)
>
> ..and a breakpoint envelope editor which needed significantly fewer  
> lines of code than the ejies ej.function.js (broadly because all the  
> mousing code is already dealt with).
>
> Anyway gong a little off topic here...so coming back to your topic:
>
> Juce also has some other neat classes, one for storing/retrieving  
> data in XML which can be easily saved to disk or kept in memory etc.  
> Then again I'm not sure if this:
>
> /Applications/Max5/MaxMSP.app/Contents/Frameworks/MaxAPI.framework/ 
> Versions/A/Headers/ext_xmltree.h
>
> ...is new to the MaxAPI (I've kept away from MaxAPI dev since Max 5  
> appeared on the horizon).
> --
> martin robinson
> max/msp java c
> installations/performance and systems

There are two strategies I am looking at: A monolithic 

object that allows you to add tracks internally to the 

object and edit all tracks within that object. Or a 

track object that is a separate element that the user 

can add to a patch as they choose. In both cases,

SDK handle storing data of externals? Ideally I would want 

the data from each track or monolithic track to be 

There are two strategies I am looking at: A monolithic 
object that allows you to add tracks internally to the 
object and edit all tracks within that object. Or a 
track object that is a separate element that the user 
can add to a patch as they choose. In both cases,
you have to worry about storing data. How will the Max5
SDK handle storing data of externals? Ideally I would want 
the data from each track or monolithic track to be 
saved in my patcher.


Have you looked at iCE Tools and Nortron? Because what you say you want to do sounds very much like what they do.

Unfortunately ICE does not do notation and is Mac only.

It was pointed out to me that the use of the past tense in my previous message may have been misleading.

The original development of both projects, which lies in the past, were extensive projects. Years (not just days or weeks) elapsed between the original concept and the first release.

Present and future development continues. In general, time between having the idea for an enhancement and implementation of same is several orders of magnitude shorter than the original project. That was the only reason I didn't use present or present continuous.

A Nortron for Windows would have been prohibitively expensive due to the Windows licensing arrangements. This has been discussed extensively in the past and I have absolutely no wish to go into it again. Max 5 is a new world in that regard, but until there is a published SDK documenting the API for UI objects, our hands are tied.

As for notation... a tracker that does CMN (conventional music notation) sort of seems like a juxtaposition of two completely disjunct paradigms.-) You are correct that we don't do this and we currently have no plans of incorporating CMN into iCE. Although it's a cute idea. Who knows what the future will bring? In the mean time, I wish you luck with the project.

The original development of both projects, which lies in the past, were extensive projects. Years (not just days or weeks) elapsed between the original concept and the first release. 

As for notation... a tracker that does CMN (conventional music notation) sort of seems like a juxtaposition of two completely disjunct paradigms.-) You are correct that we don't do this and we currently have no plans of incorporating CMN into iCE. Although it's a cute idea. Who knows what the future will bring? In the mean time, I wish you luck with the project.


Again, can someone please give me some feedback 

There are two strategies I am looking at: A monolithic

object that allows you to add tracks internally to the

object and edit all tracks within that object. Or a

track object that is a separate element that the user

SDK handle storing data of externals? Can I have separate

track externals that connect to a track storage external?

Again, can someone please give me some feedback 
on the issues below...

There are two strategies I am looking at: A monolithic
object that allows you to add tracks internally to the
object and edit all tracks within that object. Or a
track object that is a separate element that the user
can add to a patch as they choose. In both cases,
you have to worry about storing data. How will the Max5
SDK handle storing data of externals? Can I have separate
track externals that connect to a track storage external?


On 2008 May 28, at 2:01 PM, Anthony Palomba wrote:

> Again, can someone please give me some feedback

> There are two strategies I am looking at: A monolithic

> object that allows you to add tracks internally to the

> object and edit all tracks within that object. Or a

> track object that is a separate element that the user

> can add to a patch as they choose. In both cases,

> you have to worry about storing data. How will the Max5

> SDK handle storing data of externals? Can I have separate

> track externals that connect to a track storage external?

The Max 5 API uses the same sysfile_* routines that the Max 4 API 

uses. Maybe you can use those for saving data?

> Again, can someone please give me some feedback
> on the issues below...
>
> There are two strategies I am looking at: A monolithic
> object that allows you to add tracks internally to the
> object and edit all tracks within that object. Or a
> track object that is a separate element that the user
> can add to a patch as they choose. In both cases,
> you have to worry about storing data. How will the Max5
> SDK handle storing data of externals? Can I have separate
> track externals that connect to a track storage external?

The Max 5 API uses the same sysfile_* routines that the Max 4 API  
uses.  Maybe you can use those for saving data?

Developing custom track external...