instrument libraries?
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.
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.
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
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
> 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?
Yes, maxobjects.com
But there aren't many instruments for the reasons Anthony and Charles mentioned. Maybe that will change one day?
...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.
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.
If you build it...
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.
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.
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.
what do you think?
This is the way to go.
> 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
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)
* Max
Interface
* MSP
Synthesis
Input Processing
Soundfile Processing
Sequencers
* Jitter
Video Processing
3D
It's just some names examples.
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
>> 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
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
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
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.
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... :-) )
j2k
gleefully awaiting a SDK. 'Can I hey-yelp anyhows, puh-leeze?'
Anthony Palomba schrieb:
> 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
a preset and get instant gratification.
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
takes more time than just creating it...
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
version...
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 you are after...
blairell schrieb:
> 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.
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
needs to be paid...
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
specific way of controlling and playing them. It's rarely about sound
alone, the classic synthesizer approach... If you are just interested in
sounds, I guess you could just happily integrate a bunch of vst's into
your patch. A lot of them exist as pluggos with sources to dissect...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Quote: Bertrand Fraysse wrote on Fri, 23 May 2008 02:30
----------------------------------------------------
> A site where you can upload and download well defined abstractions and patches among categories is a very good idea.
>
----------------------------------------------------
mz
Quote: mzed wrote on Fri, 23 May 2008 13:05
----------------------------------------------------
> Quote: Bertrand Fraysse wrote on Fri, 23 May 2008 02:30
> ----------------------------------------------------
> > A site where you can upload and download well defined abstractions and patches among categories is a very good idea.
> >
> ----------------------------------------------------
>
> http://cnmat.berkeley.edu/library/max_msp_jitter_depot
>
Can anyone become a contributor to the depot? If so, how do you decide what files actually make it into the depot?
It would be really cool if there was a dedicated public hosting site for sharing Max stuff, where anyone could upload anything Max related. Ideally it would have "social networking" features, so people could rate patches, post comments, tag patches to categorize them, link to related patches, upload improvements to someone else's patch, etc. But that's a pretty huge undertaking, I bet.
Tim, that is great to hear. I'll definitely try and retrofit some patches soon.
Timothy Place schrieb:
>> the first two inputs & outputs being standard stereo pair if the
>> patch is stereo,
>
> What happens when you want to add more signals to the module then?
> You break all backward compatibility? The biggest things you need
> when trying to develop something that act as a general framework are
> time and users doing real projects. Both are hard to come by,
> especially given the patience of most 21st-century humans.
A better approach would be to use multicore audio connections throughout
the whole system. Then you have a single input always, but it can carry
as many audiochannels as necessary... Like in daw programs. insert a
surround plugin, and all the following objects need to deal with 5
channels, if they don't, you might just loose the 4 extra ones again,
but such is life... ;-)
> Miller once told me that Jamoma is "doomed to failure, because any
> attempt to structure Max patches in a consistent way is going against
> the very nature of Max, because Max is an endless garden of
> temptation to be unstructured."
here we get to the interesting parts of that discussion. I think the
second part of his claim is correct, but till now jamoma didn't fail,
because there is also a demand to combine the two souls in us...
> Jamoma in Max 5 is soooooo much simpler and easier to work with, but
> I guess you'll just have to trust me about that until we can get it
> released.
Looking forward to give it another try...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
On 2008 May 24, at 2:38 AM, Stefan Tiedje wrote:
> Timothy Place schrieb:
>>> the first two inputs & outputs being standard stereo pair if the
>>> patch is stereo,
>> What happens when you want to add more signals to the module then?
>> You break all backward compatibility? The biggest things you need
>> when trying to develop something that act as a general framework are
>> time and users doing real projects. Both are hard to come by,
>> especially given the patience of most 21st-century humans.
>
> A better approach would be to use multicore audio connections
> throughout
> the whole system. Then you have a single input always, but it can
> carry
> as many audiochannels as necessary... Like in daw programs. insert a
> surround plugin, and all the following objects need to deal with 5
> channels, if they don't, you might just loose the 4 extra ones
> again, but such is life... ;-)
For those who don't understand what Stefan is talking about, here is
some info on the "multicore audio connections":
http://www.bek.no/Members/lossius/lostblog/726
We currently only use them in Jamoma for ambisonic stuff because they
are a little bit of a hack. We started working on some new ideas last
year to create a proper multichannel audio cable, but it is a big
project and we have other things to do too (like Max 5 compatibility).
We are hoping to work on this later this year, though we haven't heard
from the relevant funding authorities yet to know if our application
was accepted (which is what will make it possible).
best,
Tim
Quote: Bertrand Fraysse wrote on Fri, 23 May 2008 16:24
> * Max
> Interface
>
> * MSP
> Synthesis
> Input Processing
> Soundfile Processing
> Sequencers
>
> * Jitter
> Video Processing
> 3D
>
> It's just some names examples.
>
> 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...
Just to share my 2 cents, I'm not sure a menu/sub-menu approach is the best way. The inherent modular approach make it hard for a patch to fit in a single category, imho. Personally, if a "user library" is to be set, I'd love a tag-based search system. Of course, there's still to define if the tagging system allows tags creation or just to select from a large existing tags bank. Being able to select various search criteria seems great for me. Just thinking out loud...
Best,
Julien
"i was just wondering do us max users have a user library where anyone
can upload an instrument/patch they have made?"
Nobody's mentioned this site yet:
http://www.studiotoolz.net/category/maxmsp-runtime/
They currently have 98 patches hosted, but do note that the "source"
is not available for all of them.
On Thu, May 22, 2008 at 9:49 AM, blairell wrote:
>
> 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.
>
--
Morgan Sutherland
I just add the filter by type (abstractions, externals, patches, etc.) in the maxobjects.com search engine. I hope that it will make the searches less "messy".... maxobjects.com is maybe a "mess" but imagine if it was not existing at all.
I'm working to add the same function in the "objects" page.
Indeed, we don't upgrade the site as fast as we could but :
1. We are musicians and we have many things to do
2. We maintain the site only for our purpose
3. We are not paid for that
Ninh
We've just added a filter in the www.maxobjects.com search engine to
filter by type (format) :
you can now filter by :
- abstraction
- collective
- external
- jamoma module
- javaclass (mxj)
- javacript ((js)
- javascript (jsui)
- module (UBC)
- patch
- pluggo plugin
- standalone application
this should make things easier to add / find patches in the database...
thanks Ninh !
enjoy
Mathieu
________________
Mathieu Chamagne
mathieu.chamagne@free.fr
Quote: mathieu.chamagne wrote on Sun, 25 May 2008 10:43
----------------------------------------------------
> We've just added a filter in the www.maxobjects.com search engine to
> filter by type (format) :
> you can now filter by :
> - abstraction
> - collective
> - external
> - jamoma module
> - javaclass (mxj)
> - javacript ((js)
> - javascript (jsui)
> - module (UBC)
> - patch
> - pluggo plugin
> - standalone application
>
> this should make things easier to add / find patches in the database...
>
> thanks Ninh !
>
> enjoy
>
> Mathieu
> ________________
> Mathieu Chamagne
> mathieu.chamagne@free.fr
>
> http://mathieuchamagne.com
> http://www.maxobjects.com
>
>
>
>
>
----------------------------------------------------
Nice, now it would be cool that if I let the request empty but choose javascript (jui), it outputs all the javascript (jsui) in the database...
Morgan Sutherland schrieb:
> Nobody's mentioned this site yet:
> http://www.studiotoolz.net/category/maxmsp-runtime/
>
> They currently have 98 patches hosted, but do note that the "source"
> is not available for all of them.
They only link too, and many of the links have sources...
In the end it doesn't matter if its a link or if its hosted there. The
cycling share page is the place where you can host your patches btw....
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
mathieu.chamagne@gmail.com schrieb:
> - javacript ((js)
shouldn't it be javacrypt?...
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Quote: Adam Murray wrote on Fri, 23 May 2008 13:48
----------------------------------------------------
> > ----------------------------------------------------
> > > A site where you can upload and download well defined abstractions and patches among categories is a very good idea.
> > >
> > ----------------------------------------------------
> >
> > http://cnmat.berkeley.edu/library/max_msp_jitter_depot
> >
>
> Can anyone become a contributor to the depot? If so, how do you decide what files actually make it into the depot?
>
Yes. Right now, I look at the patch and see if it works and does something useful. It's subjective. I like patches to work with OSC, if relevant. I have to stick the UC Disclaimer on them.
mz
here is a nice Pd abstractions collection and an amazing project