blairell

i was just wondering do us max users have a user library where anyone can upload an instrument/patch they have made? i have seen the user pages link, but shouldn't there be something more for us to share our work? the user area for reaktor is what makes it so great for me. i always thought it would be great if max was kinda similar in that way.

i was just wondering do us max users have a user library where anyone can upload an instrument/patch they have made?  i have seen the user pages link, but shouldn't there be something more for us to share our work?  the user area for reaktor is what makes it so great for me.  i always thought it would be great if max was kinda similar in that way.


instrument-libraries

The nice thing about Reaktor is that it has a library of 

higher level audio macros/abstractions for doing modular

synthesis. That is why the user library is so big. Unfortunately,

Max does not have this, so you have to build the low level 

pieces yourself. I would be interested to know if there

are people out there who would be interested in helping 

port the Reaktor macro library to Max. There are a ton of

The nice thing about Reaktor is that it has a library of 
higher level audio macros/abstractions for doing modular
synthesis. That is why the user library is so big. Unfortunately,
Max does not have this, so you have to build the low level 
pieces yourself. I would be interested to know if there
are people out there who would be interested in helping 
port the Reaktor macro library to Max. There are a ton of
useful things in there.


Well, nice idea, but as far as to why the existing resource sites arn't giving you what you want.....

what MAX/MSP/JITTER users often produce is not a cleanly separateable "instrument" responding to MIDI or OSC communications with audio ... 

often what I create is specifically for a large complex collection of apps and max patches (recent e.g: one patch taking MIDI and USB inputs and generating complex, "extended" OSC or MIDI, one patch just controlling output patching of the latter, sending that to a DAW running instruments under rewire control, and a final max patch that takes the DAW audio outputs and places them with processing in a "listening space"). (love that rewire..)

I could post any part of this very personal setup : but unless you want to do exactly what I've done, the only gain you'd have is use of an individual tool from the sets of tools i've used. You'd have to write your own patches to use what I produced. 

OK, we (as MSP users) can and do do that: Check out the "Max Object Database" and the users share directories... ther are SO many different types of MAX usage!

BUT if you are looking for "it's all self contained, I can play it w/ my keyboard, THEN take a look & see what was done" type patch, they are few and far between. MAX users usually use MAX/MSP/JITTER for things that standard musicians don't bother with. REACTOR ensembles are what you are looking for...

BUT (again) if you look carefully through the many HUNDREDS of patches and objects available in MAXMSP and the public sharing spots, I think you can begin to learn what MAX is good for: and that is a MUCH larger set than what reactor is "good for"...

REACTOR: 'instrument' paradigm, instant gratification.

MAX/MSP/JITTER: no defining paradigm, up to you, infinite new sounds/artistic activities.

Just my tuppence, enjoy what you will , as you will.

Well, nice idea, but as far as to why the existing resource sites arn't giving you what you want.....
what MAX/MSP/JITTER users often produce is not a cleanly separateable "instrument" responding to MIDI or OSC communications with audio ... 
often what I create is specifically for a large complex collection of apps and max patches (recent e.g: one patch taking MIDI and USB inputs and generating complex, "extended" OSC or MIDI, one patch just controlling output patching of the latter, sending that to a DAW running instruments under rewire control, and a final max patch that takes the DAW audio outputs and places them with processing in a "listening space"). (love that rewire..)
I could post any part of this very personal setup : but unless you want to do exactly what I've done, the only gain you'd have is use of an individual tool from the sets of tools i've used. You'd have to write your own patches to use what I produced. 
OK, we (as MSP users) can and do do that: Check out the "Max Object Database" and the users share directories... ther are SO many different types of MAX usage!

REACTOR: 'instrument' paradigm, instant gratification.
MAX/MSP/JITTER: no defining paradigm, up to you, infinite new sounds/artistic activities.

Just my tuppence, enjoy what you will , as you will.
l&k
CFB
aka
j2k
it's ok.


That is a good point. Max projects tend to be concept driven

pieces. So when you create a patch that implements that concept,

the patch BECOMES the piece of music. At least that is the

way I often see it. Since there is no defined interface, it 

makes it hard to share subparts without sharing the entire 

That is a good point. Max projects tend to be concept driven
pieces. So when you create a patch that implements that concept,
the patch BECOMES the piece of music. At least that is the
way I often see it. Since there is no defined interface, it 
makes it hard to share subparts without sharing the entire 
concept.


Quote: Anthony Palomba wrote on Thu, 22 May 2008 09:48

----------------------------------------------------

> That is a good point. Max projects tend to be concept driven

> pieces. So when you create a patch that implements that concept,

> the patch BECOMES the piece of music. At least that is the

> way I often see it. Since there is no defined interface, it 

> makes it hard to share subparts without sharing the entire 

(said with heavy american deep south accent) 

Quote: Anthony Palomba wrote on Thu, 22 May 2008 09:48
----------------------------------------------------
> That is a good point. Max projects tend to be concept driven
> pieces. So when you create a patch that implements that concept,
> the patch BECOMES the piece of music. At least that is the
> way I often see it. Since there is no defined interface, it 
> makes it hard to share subparts without sharing the entire 
> concept. 
>
----------------------------------------------------

wonderfully put!
j'accord par tout.
(said with heavy american deep south accent) 
;-)


Quote: blairell wrote on Thu, 22 May 2008 06:49

> i was just wondering do us max users have a user library where anyone can upload an instrument/patch they have made?

But there aren't many instruments for the reasons Anthony and Charles mentioned. Maybe that will change one day?

Quote: blairell wrote on Thu, 22 May 2008 06:49
----------------------------------------------------
> i was just wondering do us max users have a user library where anyone can upload an instrument/patch they have made? 

But there aren't many instruments for the reasons Anthony and Charles mentioned. Maybe that will change one day?


Granted, not working in max 5 yet, but it's probably the nearest thing

you'll get to Max/MSP 'instant gratification' libraries. (There are still

plenty of good Pluggos out there for earlier versions, of course - see

...and not forgetting Pluggo.
Granted, not working in max 5 yet, but it's probably the nearest thing
you'll get to Max/MSP 'instant gratification' libraries. (There are still
plenty of good Pluggos out there for earlier versions, of course - see
KVR-VST, Macmusic.org etc. etc),
Cheers
Roger

LOVE the idea of duplicating the reactor subcomponents... although given the resources applied to each one by the NI development team, you might find it is a lot of work to get the components to sounds AS GOOD as the Reactor code: often even the simple things have hidden gotchas that make their coding difficult. The whole issue of many different approaches to providing "analog warmth" comes to mind as an issue that was investigated/dicussed ("argued about") for some time before there were stable objects offered to solve these issues for some specific uses. Band-limiting signals to avoid nyquist aliasing, another issue that required actually coding new objects.

There are enough tools in Max/MSP to write the very best digital analog emulation there could be. But just hooking up a set of cycle~ objects does not quite do it. (Although it's sure is loads of fun...)

(rural southern fire an' brimstone preacher voice:)

I say, people, revel in 'da pow-wer of the to-ols! but don't expect 'em to build the house for you. 

j2k (pooh, the db is rebuilt, no more goofin' off...)

p.s.: oh, and I second the pluggo recomendation....great way to start finding uses for MAXMSP.

LOVE the idea of duplicating the reactor subcomponents... although given the resources applied to each one by the NI development team, you might find it is a lot of work to get the components to sounds AS GOOD as the Reactor code: often even the simple things have hidden gotchas that make their coding difficult. The whole issue of  many different approaches to providing "analog warmth" comes to mind as an issue that was investigated/dicussed ("argued about") for some time before there were stable objects offered to solve these issues for some specific uses. Band-limiting signals to avoid nyquist aliasing, another issue that required actually coding new objects.
Indeed,
There are enough tools in Max/MSP to write the very best digital analog emulation there could be. But just hooking up a set of cycle~ objects does not quite do it. (Although it's sure is loads of fun...)
soo.....
(rural southern fire an' brimstone preacher voice:)
I say, people, revel in 'da pow-wer of the to-ols! but don't expect 'em to build the house for you. 
:) 
j2k (pooh, the db is rebuilt, no more goofin' off...)
p.s.: oh, and I second the pluggo recomendation....great  way to start finding uses for MAXMSP.


what about those people who want to share the whole concept? I'm one of them. i spent weeks programming a sequencer for my lemur and i shared it on the lemur forum. but im sure this community could take a whole new collective edge once people started sharing their amazing inventions. some wont want to, but you start the ball rolling and it would be great.

what about those people who want to share the whole concept?  I'm one of them.  i spent weeks programming a sequencer for my lemur and i shared it on the lemur forum.  but im sure this community could take a whole new collective edge once people started sharing their amazing inventions.  some wont want to, but you start the ball rolling and it would be great.


i think c74 with max 5 release moved in this direction (start building a macro-module collection, instrument library) with some amazing example patches: fm synth patch, and all the cyclist music folder..of course would be great to have a complete collection of ready to use instruments!

A site where you can upload and download well defined abstractions and patches among categories is a very good idea.

If it happens, a very important thing, at least for me, is to keep things very classified and clean.

The max msp forum (here) is a nice place but it's impossible to find a previous thing posted unless you really search for it.

If things are classified, with upper and lower categories, it's a lot easier to find things, a lot easier to learn new things.

If it happens, a very important thing, at least for me, is to keep things very classified and clean.
The max msp forum (here) is a nice place but it's impossible to find a previous thing posted unless you really search for it.
If things are classified, with upper and lower categories, it's a lot easier to find things, a lot easier to learn new things.


Another issue besides clear organization of these patches/externals 

avoid hard coding sampling rate into the patch, 

the first two inputs & outputs being standard stereo pair if the patch is stereo,

patches should have control patch through available,

As you can see these are not simple decisions and should be at least discussed before the effort gets too much attention, so that the work is at least as well directed as these communal efforts can be....

so someone with the appropriate qualifications can take a first crack at such a document, make it public, and we can pass it through community process a bit & create a 

MAX/MSP/JITTER public lib design/best practice document.

After the SDK, since part of this doc would involve external creation and embedded language programming.

Another issue besides clear organization of these patches/externals  
is a clear set of coding standards 
such as 
avoid hard coding sampling rate into the patch, 
the first two inputs & outputs being standard stereo pair if the patch is stereo,
patches should have control patch through available,
etc.

so someone with the appropriate qualifications can take a first crack at such a document, make it public, and we can pass it through community process a bit & create a 
MAX/MSP/JITTER public lib design/best practice document.

> As you can see these are not simple decisions and should be at least discussed before the effort gets too much attention, so that the work is at least as well directed as these communal efforts can be....

Perhaps you should google the word "Jamoma" and see what you find.

Yes, Jamoma is exactly that, a standardized interface for 

programming in Max. The problem is that it is overly complicated,

I really don't have time to learn another build interface.

In the time it takes to learn, I will have built what I needed.

Which does not solve the problem of making sharing easier.

Maybe I am just lazy but, I really think we need a simpler set 

Yes, Jamoma is exactly that, a standardized interface for 
programming in Max. The problem is that it is overly complicated,
I really don't have time to learn another build interface.
In the time it takes to learn, I will have built what I needed.
Which does not solve the problem of making sharing easier.
Maybe I am just lazy but, I really think we need a simpler set 
of guidelines rather than Jamoma.


I agree with the fact that Jamoma is too comlpicated (or at least, need the user an adaptative time).

Things can keep really simple and intuitive (for max users).

Abstractions with well defined inlets and outlets could be enough.

And I don't think maxobjects is the thing we are talking about.

A user library should look like something like this (it's just some example)

Maybe some of you would think it's restrictive, but it's up to us to add important sub-menus and sub-classifications...

It's important for users to understand, to start from simple to complex menus and guide them to what they really search...

I agree with the fact that Jamoma is too comlpicated (or at least, need the user an adaptative time).
Things can keep really simple and intuitive (for max users).
Abstractions with well defined inlets and outlets could be enough.

And I don't think maxobjects is the thing we are talking about.
A user library should look like something like this (it's just some example)

* MSP
Synthesis
Input Processing
Soundfile Processing
Sequencers

Maybe some of you would think it's restrictive, but it's up to us to add important sub-menus and sub-classifications...
It's important for users to understand, to start from simple to complex menus and guide them to what they really search...


On 2008 May 23, at 8:47 AM, mathieu.chamagne@gmail.com wrote:

>> Perhaps it would be possible to adopt something like Reaktors 

>> - the subest level (Reaktor-Core-like) - "dataflow-level" (like 

>> most of the stuff from maxobjects.com)

>> - basic building blocks (already analog-smoothed- osc, filters, 

>> - Composition - "individual patch, generating a whole piece"

> "Jamoma provides a clear structure and common features for building 

> max patches. Reducing the amount of time needed to create new 

> performance systems, and enhancing the interchange of patches 

I'll also make mention that there will be some Jamoma activity 

surrounding the NIME conference in a couple of weeks. In addition to 

a paper/poster, there is a workshop where Jamoma will be demonstrated 

We've done several of these workshops, and the best part is that the 

discussion part of them is a two-way discussion -- Jamoma is still 

being molded into a form that meets the need of a growing community. 

So if you're interested, please check it out.

Finally, as with all third-party extensions for Max, there is the 

caveat that support for Max 5 is still in-progress. We will be able 

to show Jamoma in Max 5 at NIME, and hope to have a new version stable 

>> Perhaps it would be possible to adopt something like Reaktors  
>> Patchlevel-Order:
>> - the subest level (Reaktor-Core-like) - "dataflow-level" (like  
>> most of the stuff from maxobjects.com)
>> - basic building blocks (already analog-smoothed- osc, filters,  
>> etc ) - "signal-level"
>> - Instruments - "user-level"
>> - Composition - "individual patch, generating a whole piece"
>
> you should have a look at jamoma : http://www.jamoma.org/
> "Jamoma provides a clear structure and common features for building  
> max patches. Reducing the amount of time needed to create new  
> performance systems, and enhancing the interchange of patches  
> amongst max users."
> :-)

I'll also make mention that there will be some Jamoma activity  
surrounding the NIME conference in a couple of weeks.  In addition to  
a paper/poster, there is a workshop where Jamoma will be demonstrated  
and discussed.

We've done several of these workshops, and the best part is that the  
discussion part of them is a two-way discussion -- Jamoma is still  
being molded into a form that meets the need of a growing community.   
So if you're interested, please check it out.
	http://nime2008.casapaganini.org/

Finally, as with all third-party extensions for Max, there is the  
caveat that support for Max 5 is still in-progress.  We will be able  
to show Jamoma in Max 5 at NIME, and hope to have a new version stable  
within a month.

best,
   Tim
_________________
Tap.Tools / Teabox / Hipno / Hemisphere
http://electrotap.com


>>I agree with the fact that Jamoma is too comlpicated

I think I mentioned to tim at one point, and now I'll mention it here.

As I remember (it was a while ago), jamoma isn't actually that complicated to develop for. it just seems that way because the innards are abstractions and not max externals. The thing was that there is no clear line apparent to the user of jamoma what is for the "end user", the "jamoma module developer" and the "jamoma developer" In general, It just seemed like a lot of max work to do something an external might have done easily.

I'm personally on a mission to develop what I want which is a system wide pattrified modulator matrix. three objects

similar to that of the TC electronic Fireworx. That box is life.

>>I agree with the fact that Jamoma is too comlpicated 

I think I mentioned to tim at one point, and now I'll mention it here.  

As I remember (it was a while ago), jamoma isn't actually that complicated to develop for. it just seems that way because the innards are abstractions and not max externals.  The thing was that there is no clear line apparent to the user of jamoma what is for the "end user", the "jamoma module developer" and the "jamoma developer"  In general, It just seemed like a lot of max work to do something an external might have done easily.

I'm personally on a mission to develop what I want which is a system wide pattrified modulator matrix. three objects
parameter display in
modulator signal in
algorithm value out

similar to that of the TC electronic Fireworx.  That box is life.


I think the problem with Jamoma is once you get used to having 

to build things your way, you don't like using other peoples 

architecture. By now I have already developed my own performance 

architecture that I feel very comfortable with and works very well.

I am not really interested in throwing that away in favor of 

Jamoma. Maybe had Jamoma been brought to my attention when 

I first started using Max I would have adopted it. I think there 

are many who feel the same way, which is why I think Jamoma is

But Jamaoma does not address the issue of instrument libraries.

What would be much more useful would be a Reaktor like macro 

library. Which is a set of building blocks for doing modular 

synthesis and sampling. I don't think it would be too hard

to port the Reaktor library. If there are enough people

Maxobjects.com needs a complete over haul, it is really a mess. 

It is not categorized in any way which makes finding things 

difficult. Who is in charge of that thing anyways? I hope 

I think the problem with Jamoma is once you get used to having 
to build things your way, you don't like using other peoples 
architecture. By now I have already developed my own performance 
architecture that I feel very comfortable with and works very well.
I am not really interested in throwing that away in favor of 
Jamoma. Maybe had Jamoma been brought to my attention when 
I first started using Max I would have adopted it. I think there 
are many who feel the same way, which is why I think Jamoma is
not used that much.

But Jamaoma does not address the issue of instrument libraries.
What would be much more useful would be a Reaktor like macro 
library. Which is a set of building blocks for doing modular 
synthesis and sampling. I don't think it would be too hard
to port the Reaktor library. If there are enough people
interested we could split up the work.

Maxobjects.com needs a complete over haul, it is really a mess. 
It is not categorized in any way which makes finding things 
difficult. Who is in charge of that thing anyways? I hope 
they are reading this...

talking about reaktor ensambles this was inspired by new-school ensemble

https://cycling74.com/forums/index.php?t=msg&th=33859&start=0&rid=1684&S=2dfc8f89ceda97ef1c90cf4a5c9c608e

quoting me>> As you can see these are not simple decisions and should be at least discussed before the effort gets too much attention, so that the work is at least as well directed as these communal efforts can be....

>Perhaps you should google the word "Jamoma" and see what you find.

I have the Jamona stuff, have had for several releases, and much about it is good, but not clearly documented: if you're a patch ripperapart kinda maxer, it has lotsa good practice / clever tricks indeed. Buuuttt....

If it's a question of a newer max user actually using a jamona module as a template for their new module, welll... it's really a very advanced set of practices, and need much more tutorial/ descriptive text to even begin to reach the maxing masses, as opposed to max cogniscenti.

Not to mention, being so fully implemented, it really tends to lock one into the Jamona style: which is *good* , but completes the picture of why maybe it has not so much appeal with the more advanced max user, grown accustommed to their own maxing style.

Perhaps I'm just subliminally pulling for a open-source style RFC cycle or two on this important stuff... there are great ui devs out there would might chip in for free, and i'm sure there are devs who would like to put their little word or three into the process, etc.,etc. After all, it's a commercial product, but it's a large diverse international community.

Gotta put a shout out to Tim's TAP tools, though!! What a wonderfully useful bunch of objects!!!! woo , go buy! (oh, and also buy from all the other hard working folk selling their max libs... :-) )

gleefully awaiting a SDK. 'Can I hey-yelp anyhows, puh-leeze?'

Gregory Taylor wrote:
 quoting me>> As you can see these are not simple decisions and should be at least discussed before the effort gets too much attention, so that the work is at least as well directed as these communal efforts can be....

>Perhaps you should google the word "Jamoma" and see what you find. 

Greg,
I have the Jamona stuff, have had for several releases, and much about it is good, but not clearly documented: if you're a patch ripperapart kinda maxer, it has lotsa good practice / clever tricks indeed. Buuuttt....
If it's a question of a newer max user actually using a jamona module as a template for their new module, welll... it's really a very advanced set of practices, and need much more tutorial/ descriptive text to even begin to reach the maxing masses, as opposed to max cogniscenti.

j2k
gleefully awaiting a SDK. 'Can I hey-yelp anyhows, puh-leeze?'


> Since there is no defined interface, it makes it hard to share 

> subparts without sharing the entire concept.

That does describe it very well, another point is, that many Max users

choose their tool because they needed a different approach than pushing

When I started with Max I had a DX 7. I was doing a lot of sounds, I

mean a lot. I was sharing them with friends freely. Once George Lewis 

said there is more Stefan to hear in these concerts than most are aware 

of, becaus my friends shared my patches as well... ;-). But I almost 

never used patches from others, I found out, that searching for a sound 

The same is true for effects. I almost never use 3rd party VST's...

With creating synth sounds it's simple, you just share them and anybody

can use them directly or as a base for creating their own modified 

With Max its a bit more complicated. What is shared is rarely directly

usable. You have to understand and integrate it into your own creation.

And have a look at Jamoma, its a framework with some standard interfaces

which would allow to share a more standardized subsets of patches. It

does has its own learning curve, and at the moment the user base hasn't

reached the critical mass. But it would be the most prominent path to

> what about those people who want to share the whole concept? I'm one

> of them. i spent weeks programming a sequencer for my lemur and i

> shared it on the lemur forum. but im sure this community could take a

> whole new collective edge once people started sharing their amazing

> inventions. some wont want to, but you start the ball rolling and it

Yes, that is possible, but there is a problem: If I take my Ondes 

Memorielles, I have no problem to share it, but its not "The Universal 

Tool", its a very personal tool, I know it well, I made it...

But I doubt its even close to being very usable for others. To turn it 

into something shareable it would need a lot of extra work...

The biggest benefit might be just as a source of inspiration. Giving 

ideas to create your own instrument. There are a lot around. Lloopp 

comes to mind with its own user base and community, Kenaxis, which is 

adapted for a bigger user base, but the effort for that additional work 

All these tools are more like separate open source applications, with 

their own learning curve, but written in the language we love...

All these examples have one thing in common. They are instruments with a 

instrument libraries?