Forums > Dev

Developing custom track external…

May 21, 2008 | 9:37 pm

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?


May 22, 2008 | 6:48 am

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


May 22, 2008 | 1:56 pm

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.

best,
Tim

____________________________________
Tap.Tools – Objects for Max, MSP, and Jitter

http://electrotap.com/taptoolsmax/

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


May 23, 2008 | 6:42 pm

If I could get some feed back on this…

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.


May 24, 2008 | 9:45 am

Hi Anthony,

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

Both were very extensive projects.

Best — Peter


May 24, 2008 | 9:46 am

Hi Anthony,

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

Both were very extensive projects.

Best — Peter


May 24, 2008 | 2:23 pm

Unfortunately ICE does not do notation and is Mac only.


May 27, 2008 | 10:13 am

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.


May 28, 2008 | 7:01 pm

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?


May 28, 2008 | 7:06 pm

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

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

best,
Tim


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