estevancarlos

https://cycling74.com/wiki/index.php?title=BEAP_Analog_Model_Curriculum_Outline

In a sense it looks reminiscent of Reaktor and I'm wondering why this doesn't seem to be a more commonplace approach in this community. The approach revolving around higher level, modular, components.

I think when I first came across Max (probably a decade or so ago) it was easy to make comparisons to Reaktor and at the time I couldn't tell if it was technical differences that led to this lack of higher level parts in Max. However I understand very easily now that there are no technical issues, it's cultural or stylistic.

Why do you think that is? Is it something promoted from Cycling74? Is it an aspect of the community that just evolved over time? Do people just prefer to do things a certain way?

One comparison I think of is in the web development framework/CMS community. There are two different but almost similar tools of Wordpress and Drupal. Wordpress has plugins which are often out-of-the-box solutions that serve specific targeted needs. Drupal however revolves around modular tools called "modules" and the community doesn't have a history of providing tools that can function independently on their own. The issue is that the technologies behind both promote these different approaches. I'm not sure I understand what motivates the Max community though. Thoughts?

Here's more on Beap - https://cycling74.com/wiki/index.php?title=BEAP_Analog_Model_Curriculum_Outline

In a sense it looks reminiscent of Reaktor and I'm wondering why this doesn't seem to be a more commonplace approach in this community.  The approach revolving around higher level, modular, components.

I think when I first came across Max (probably a decade or so ago) it was easy to make comparisons to Reaktor and at the time I couldn't tell if it was technical differences that led to this lack of higher level parts in Max.  However I understand very easily now that there are no technical issues, it's cultural or stylistic.  

Why do you think that is?  Is it something promoted from Cycling74?  Is it an aspect of the community that just evolved over time?  Do people just prefer  to do things a certain way?

One comparison I think of is in the web development framework/CMS community.  There are two different but almost similar tools of Wordpress and Drupal.  Wordpress has plugins which are often out-of-the-box solutions that serve specific targeted needs.  Drupal however revolves around modular tools called "modules" and the community doesn't have a history of providing tools that can function independently on their own. The issue is that the technologies behind both promote these different approaches.  I'm not sure I understand what motivates the Max community though.  Thoughts?


why-arent-there-more-higher-level-modular-components-like-beap

not sure what you mean when you say there are not many modular systems.

well, i also only know 6 or 7 sets of modular objects ... but if you think there should be more, there is something you can do: build some ...

Oh ok, that in case I haven't really come across many. I'm certainly interested in learning more. Do you have any links?

Regarding building more, well sure. Yeah, I hope to eventually learn how to do that effectively but my question is really about whether there was a preference in the community. Modular development doesn't seem to be very common and I'm wondering if there's a reason. Unless you think it is common? What are these projects you're referring to?

Oh ok, that in case I haven't really come across many.  I'm certainly interested in learning more.  Do you have any links?

Regarding building more, well sure.  Yeah, I hope to eventually learn how to do that effectively but my question is really about whether there was a preference in the community.  Modular development doesn't seem to be very common and I'm wondering if there's a reason.  Unless you think it is common?  What are these projects you're referring to?


vizzie, Roman's own set of modular patchs (which i don't think he distributes ;) ), RTC library and, well... i don't see much more, but maybe i don't know them.

though it might indeed be a matter of culture, because imho max users are more programmers and do more things that would not benefit, most of the time, of a modular set of tools.

vizzie, Roman's own set of modular patchs (which i don't think he distributes ;) ), RTC library and, well... i don't see much more, but maybe i don't know them.
though it might indeed be a matter of culture, because imho max users are more programmers and do more things that would not benefit, most of the time, of a modular set of tools.


I think one reason this modularity crosses my mind is regarding the Max4Live community. There are now Live9 owners who have this copy of Max they are, frankly, unable/unwilling to use. I think more modular tools could benefit that audience.

I think one reason this modularity crosses my mind is regarding the Max4Live community.  There are now Live9 owners who have this copy of Max they are, frankly, unable/unwilling to use.  I think more modular tools could benefit that audience.


Most people are building for their own projects, often that have very specific requirements.

Part of the reason why there's less reuse is also part of how max works. Most organization is on an ad hoc basis, and most users probably don't have a CS background, so things like Git aren't on most users' radar. Philosophically, max users tend to be fractious; it's not like Python which tends to emphasize a "right way" of doing things.

I was working on my own modular library for a while, but am merging it into BEAP. Writing code with others requires compromise. My library uses different conventions and makes different assumptions about the end user. BEAP is more end-to-end whereas my lib assumed that it would be in the mix of other MSP code and that users would create their own interface code. They're both totally valid approaches, just with different focuses.

Max being max, there's probably a higher than average level of iconoclasts in our ecosystem.

Part of the reason why there's less reuse is also part of how max works.  Most organization is on an ad hoc basis, and most users probably don't have a CS background, so things like Git aren't on most users' radar.  Philosophically, max users tend to be fractious; it's not like Python which tends to emphasize a "right way" of doing things.  

I was working on my own modular library for a while, but am merging it into BEAP.  Writing code with others requires compromise.  My library uses different conventions and makes different assumptions about the end user.  BEAP is more end-to-end whereas my lib assumed that it would be in the mix of other MSP code and that users would create their own interface code.  They're both totally valid approaches, just with different focuses. 

Max being max, there's probably a higher than average level of iconoclasts in our ecosystem.


I'm in a laptop orchestra, and we've been all over BEAP for the last couple of months.

We've got some special sync and harmony-control stuff going on over OSC, and we're working on modularizing a lot of those things. So far I've got a clock generator for OSC and a basic, OSC-ready step sequencer as a proof of concept - the clock is already in play, side by side with BEAP.

The REALLY good thing about BEAP is the clippings-aspect of it, with the bpatcher-reaktor-like look. It works for vizzie too, but it's really interesting the way you can do that reaktor-style rapid prototyping now.

Oh, and our trick is to install the clippings folder on a google-drive folder that's exposed to the max folder prefs. This means that I can update BEAP locally, and the update will sync out to the rest of the band members automagically.

I'm in a laptop orchestra, and we've been all over BEAP for the last couple of months. 

Oh, and our trick is to install the clippings folder on a google-drive folder that's exposed to the max folder prefs. This means that I can update BEAP locally, and the update will sync out to the rest of the band members automagically. 

Rotating clock divider coming soon to BEAP (at audio rate), btw...

Yeah, this might be analogous to the framework system, Drupal (I know there may not be too many web devs here but we're all nerds so maybe the analogy makes sense). In the Drupal system it seems a similar thing has occurred where people's needs are so specific, that there are "modules" offered but there are such a wide variety as result of narrow needs that it has become hairy finding what modules you really need. I think the process has become problematic but it still works.

I think as the Max community increases (which it will) modularity will be more useful. Again, we now have the Ableton Live community (which is mostly the angle I'm coming from) and that's an audience that definitely needs certain kinds of functionality. Which is one reason Beap makes so much sense. For example there's a set a common synthesis needs that the Live community might often use. I can envision a modular toolset there.

Also, I'm not complaining or suggesting that someone else needs to code this. I'm just wondering about the norms and traditions of the programming community here.

Yeah, this might be analogous to the framework system, Drupal (I know there may not be too many web devs here but we're all nerds so maybe the analogy makes sense).  In the Drupal system it seems a similar thing has occurred where people's needs are so specific, that there are "modules" offered but there are such a wide variety as result of narrow needs that it has become hairy finding what modules you really need. I think the process has become problematic but it still works.

I think as the Max community increases (which it will) modularity will be more useful.  Again, we now have the Ableton Live community (which is mostly the angle I'm coming from) and that's an audience that definitely needs certain kinds of functionality.  Which is one reason Beap makes so much sense.  For example there's a set a common synthesis needs that the Live community might often use.  I can envision a modular toolset there.

Also, I'm not complaining or suggesting that someone else needs to code this.  I'm just wondering about the norms and traditions of the programming community here.


"Max being max, there’s probably a higher than average level if iconoclasts in our ecosystem."

I can see that and so that may answer my question. It seems like the code is the art here, and that art needs to be controlled by the artist, in many circumstances.

I can see that and so that may answer my question.  It seems like the code is the art here, and that art needs to be controlled by the artist, in many circumstances.


(bpatchers, probably inspired by argo but i would never confess that, around 2007)

(bpatchers, cheap and failed attempt to copy me =], around 2009)

then around 2010 or so, beap (bpatchers) and bach (externals) were born.

i am also aware of jamoma and leafcutter framework, but i dont know much about these, or of they would fit into this category.

there are also 2 or 3 more people using bpatchers, which are private and/or max4live only (which i dont have.), plus some smaller work (probably students work) like eurorack, and some synth i´ve seen.

bach and beap are great stuff, but i dislike a bit when something is a closed system, they both dont have a lot of interfaces which you an extend by programming (in opposite to 110.modular or vizzie, which are using numbers and have linear parameters most of the time)

oh, and lets not forget that there was pluggo for Mac OS Classic, which had send and receive, plugmod and plugmorph, pluggo shell and all this voodoo, which could turn you cubase/nuendo into a modular effect workstation unique in these days. pluggo probably inspired ME to create bpatcher systems more than anything else. secretly i am calling my modules my "plug-ins" until today.

110.modular and 110.fmm
(bpatchers, probably inspired by argo but i would never confess that, around 2007)

vizzie
(bpatchers, cheap and failed attempt to copy me =], around 2009)

Is BEAP available? If so, how does one get it?

please read the instructions there carefully.

I was planning to create a modular environment for my dissertation similar to BEAP and then I found BEAP and said hmm…

…but I'm still working on my project because part of it is to document the devices in layers. So the outer module has self-contained documentation but then the user can go deeper into how the device was made in Max and then even further into Gen patchers to show lower-level DSP (I have a lot of work to do!).

I would like to see the BEAP library fully documented in this way. As it stands the devices themselves are awesome but once you open them they're relatively messy with no documentation. Of course that's because learning how the devices themselves work is not the point of BEAP, but I still think it would be cool to add that layer for those who are interested.

The model I'm thinking of is the way pretty much every M4L device and abstraction is meticulously documented.

...wouldn't a documentation set for BEAP be a great idea for a dissertation?

But yes, for a pedagogical system, a full set of docs - deep and rich - would be extremely helpful.

This is also something that could be contributed by users (in addition to the people writing the code...aka code janitoring); it's a great way to learn how things work.

CNMAT tried to make something useful with the MMJ Depot:

@mzed Cool stuff, I missed that there were pieces in that.

For those who are new to BEAP, there are two ways to get it: via zip archive, and via Git. (both are available on the site) If you choose the latter, you can quickly update to the latest and greatest, simply by syncing in the GitHub app.

Since BEAP is based off of pasted bpatchers, your older patches made with BEAP won't change when you get the new version.

For those who are new to BEAP, there are two ways to get it: via zip archive, and via Git.  (both are available on the site)  If you choose the latter, you can quickly update to the latest and greatest, simply by syncing in the GitHub app. 

Since BEAP is based off of pasted bpatchers, your older patches made with BEAP won't change when you get the new version.


The kind of modularity that's being described makes more sense (IMO) in the world of beat based music. Repeating music with repeating methods of production (or at least, a particular commonality of approach (and yes, even as I type this I realise that this is an over-generalisation)).

(And the growth of that style of music came _relatively recently in Max's lifespan. (Cassiel excepted). Or perhaps the introduction of winmax would be a more appropriate marker. Could be wrong. Just a thought)

Now, I tend to use the same types of process every time I build something new, because after all these years I've settled on a particular sound. And way of working. However, when i've looked at things like jamoma in the past (curious about the usefulness of being able to put something together fairly quickly with standard modules) I've found that there's always something I want to do slightly differently (especially around the UI) from the standard modules.

I have standardised somewhat around sub-patchers, but even there I find that I still end up changing processes at that level on a per-project basis.

And the other thought is- wouldn't you say that max _is already modular in that way, but just at a lower level. Max's high level is, in terms of the way it's traditionally been used, parallel with Reaktor's higher levels. (I think that's actually how I used to think of it).After all, I suspect that most of us are _not building objects in C, or composition specific objects in gen~. (Now there's an area I'd love to see more sharing in (or paid-for sharing in - people's hard work should be rewarded) - non-standard processes created in gen~).

Oh well, this may all just be ramblings inspired by being woken early by great blasts of wind (outside, I hasten to add. Top window got sucked open by a huge gust an hour ago, along with the wind chimes, which I've been listening to ever since).

And just checking out BEAP ... isn't that kind of standardisation and limitation exactly why (at least in the "old days") people began using max? (That's not in any way a criticism of BEAP, which I think demonstrates how much max has expanded beyond its original purposes). _my original impetus was frustration with the fixed limitations of LiSa, which was (and is) really good at one specific thing, but frustratingly closed at others (looks like RoSa may well change that though).

The kind of modularity that's being described makes more sense (IMO) in the world of beat based music. Repeating music with repeating methods of production (or at least, a particular commonality of approach (and yes, even as I type this I realise that this is an over-generalisation)).
(And the growth of that style of music came _relatively recently in Max's lifespan. (Cassiel excepted). Or perhaps the introduction of winmax would be a more appropriate marker. Could be wrong. Just a thought)
Now, I tend to use the same types of process every time I build something new, because after all these years I've settled on a particular sound. And way of working. However, when i've looked at things like jamoma in the past (curious about the usefulness of being able to put something together fairly quickly with standard modules) I've found that there's always something I want to do slightly differently (especially around the UI) from the standard modules.
I have standardised somewhat around sub-patchers, but even there I find that I still end up changing processes at that level on a per-project basis.
And the other thought is- wouldn't you say that max _is already modular in that way, but just at a lower level. Max's high level is, in terms of the way it's traditionally been used, parallel with Reaktor's higher levels. (I think that's actually how I used to think of it).After all, I suspect that most of us are _not building objects in C, or composition specific objects in gen~. (Now there's an area I'd love to see more sharing in (or paid-for sharing in - people's hard work should be rewarded) - non-standard processes created in gen~).
Oh well, this may all just be ramblings inspired by being woken early by great blasts of wind (outside, I hasten to add. Top window got sucked open by a huge gust an hour ago, along with the wind chimes, which I've been listening to ever since).

And just checking out BEAP ... isn't that kind of standardisation and limitation exactly why (at least in the "old days") people began using max? (That's not in any way a criticism of BEAP, which I think demonstrates how much max has expanded beyond its original purposes). _my original impetus was frustration with the fixed limitations of LiSa, which was (and is) really good at one specific thing, but frustratingly closed at others (looks like RoSa may well change that though).


this is maybe one of the reasons why people dont like to build bigger modules, you loose flexibility if you do.

orin other words: if you build modules, try to keep them as small as possible.

think "abstraction", and generalize things.

otherwise you will might up with something like _reason, _modularing or _numerology.

if you build a set of modules for composition, midi processing, effects mangling or synthesis, the result should be something where the biggest part of working with it is connecting the modules – and not doing settings on the modules. keep it max/msp. modules are not virtual devices, they are max objects, you want to program with them.

orin other words: if you build modules, try to keep them as small as possible.
think "abstraction", and generalize things. 

if you build a set of modules for composition, midi processing, effects mangling or synthesis,  the result should be something where the biggest part of working with it is connecting the modules – and not doing settings on the modules. keep it max/msp. modules are not virtual devices, they are max objects, you want to program with them.

I think the answer is that most people do end up rolling their own eventually - you find yourself repeating/re-using certain things, so you find your own way of simplifying that processes - but this is not a process that generally starts with other users in mind.

The most tedious part of most projects - and consequently one with which most people can't be arsed - is the documentation.

You see it a lot with Max. Somebody shares something wonderful, you see it demo'd on Youtube and think "I want some of that", but when you get it, you play with it for five minutes and then it goes back in the toy box because the learning curve is too steep.

From it's creator's point of view, it's obvious what it does and how you use it, but to anyone else...

I have my own little modular thing which works for me and I like to think saves me some time, but to make it shareable - well, that just keeps going to the back of the queue.

(and as a Pluggo fan like Roman, I also call my system 'Plugginz'!)

That said, BEAP is very nice and does seem to be gathering momentum, so getting it properly documented would be a bonus.

And I agree with David's point about standardisation and limitation - it's probably why the whole Live/M4L thing never really did it for me, whereas Pluggo at least allowed me to stay with my DAW of choice.

(Sounds like you're having more fun with the storm than we are here, David - a lot of rain, but that's hardly news in Wales!)

I think the answer is that most people do end up rolling their own eventually - you find yourself repeating/re-using certain things, so you find your own way of simplifying that processes - but this is not a process that generally starts with other users in mind.
The most tedious part of most projects - and consequently one with which most people can't be arsed - is the documentation.
You see it a lot with Max. Somebody shares something wonderful, you see it demo'd on Youtube and  think "I want some of that", but when you get it, you play with it for five minutes and then it goes back in the toy box because the learning curve is too steep.
From it's creator's point of view, it's obvious what it does and how you use it, but to anyone else...
I have my own little modular thing which works for me and I like to think saves me some time, but to make it shareable - well, that just keeps going to the back of the queue.
(and as a Pluggo fan like Roman, I also call my system 'Plugginz'!)
That said, BEAP is very nice and does seem to be gathering momentum, so getting it properly documented would be a bonus.
And I agree with David's point about standardisation and limitation - it's probably why the whole Live/M4L thing never really did it for me, whereas Pluggo at least allowed me to stay with my DAW of choice.
(Sounds like you're having more fun with the storm than we are here, David - a lot of rain, but that's hardly news in Wales!)
Cheers
Roger


This is also something that could be contributed by users (in addition to the people writing the code…aka code janitoring); it’s a great way to learn how things work.

Just contacted Matthew Davidson to ask about contributing documentation to the BEAP library.

And yes, documenting in order to understand how the modules work is my not-so-ulterior motive!

i am just looking at this MMJ. typically academic ***.

beside the fact that nobody needs somebody else to make him a delay/flanger/ringmod/tremolo, it seems to completely ignore some of the things which would be required for a software to be used by others.

one of these things is the naming convention. MMJ really puts you files in the search path called "onepole.maxpat", "zeros.maxpat", or "bassdrum.aiff".

and its internal OSC data send/receive uses the totally unique name "s OSC" ... happy stack overflow!

i am sure it works totally great when it is the only thing installed - but its gonna be hard to use 3 of such projects together. :P

i am sure it works totally great when it is the only thing installed – but its gonna be hard to use 3 of such projects together. :P

Part of this complaint can be thrown on back on Max itself. We debated calling everything cnmat.onepole.maxpat, or the like, but it seemed too unwieldy. Now that the packages feature is getting straightened out, it might be nice to have a syntax like cnmat::onepole, or something, to help disambiguate these things. FWIW, I've had it all in my searchpath for years and it's been ok.

...nobody needs somebody else to make him...

Most of the things in this collection came out of actual projects. In this case, it was a sensor class where the students didn't know Max. We wanted to get them moving quickly, so provided a bunch of typical effects.

I was never totally comfortable with that implementation. It suggests an interesting way to organize Max patchers, but it might be impractical. The name "OSC" is purposely generic, with the intent that the namespace is generated partially by the user. I think you're calling out the problem that using CNMAT modules in abstractions is going to generate duplicate namespaces, making this scheme unusable. Unfortunately, it's true. This "s OSC" bus is very convenient on a certain level, but it doesn't scale. In design discussions, we concluded that users working at that scale would need to be responsible for these namespace collisions. Also, you're suggesting that all of the communications going into the same queue is going to lead to stack overflow. While I've never seen this in practice, it is possible. Tangentially, this was implemented in anticipation of John MacCallum's o.dot objects, which work on actual OSC-packets (rather than OSC-style max messages).

All that being said, I agree that the CNMAT MMJ Depot is flawed. It's hard to find what you're looking for in there. Items created for absolute beginners are next to ones that are extremely nuanced and only need for experts in special situations. We tried, in most cases, to avoid telling users that "this thing is for this purpose"; the spirit of Max seems to be one of creative (re/mis)use. But, the result is something of an unguided tour through the Max Id of an idiosyncratic research unit. Is it an offering of higher-level components, or an ironic critique of such libraries?

Part of this complaint can be thrown on back on Max itself.  We debated calling everything cnmat.onepole.maxpat, or the like, but it seemed too unwieldy. Now that the packages feature is getting straightened out, it might be nice to have a syntax like cnmat::onepole, or something, to help disambiguate these things.  FWIW, I've had it all in my searchpath for years and it's been ok.  

Most of the things in this collection came out of actual projects.  In this case, it was a sensor class where the students didn't know Max.  We wanted to get them moving quickly, so provided a bunch of typical effects.

I was never totally comfortable with that implementation.  It suggests an interesting way to organize Max patchers, but it might be impractical. The name "OSC" is purposely generic, with the intent that the namespace is generated partially by the user. I think you're calling out the problem that using CNMAT modules in abstractions is going to generate duplicate namespaces, making this scheme unusable.  Unfortunately, it's true.  This "s OSC" bus is very convenient on a certain level, but it doesn't scale. In design discussions, we concluded that users working at that scale would need to be responsible for these namespace collisions. Also, you're suggesting that all of the communications going into the same queue is going to lead to stack overflow.  While I've never seen this in practice, it is possible. Tangentially, this was implemented in anticipation of John MacCallum's o.dot objects, which work on actual OSC-packets (rather than OSC-style max messages).

All that being said, I agree that the CNMAT MMJ Depot is flawed.  It's hard to find what you're looking for in there.  Items created for absolute beginners are next to ones that are extremely nuanced and only need for experts in special situations.  We tried, in most cases, to avoid telling users that "this thing is for this purpose"; the spirit of Max seems to be one of creative (re/mis)use. But, the result is something of an unguided tour through the Max Id of an idiosyncratic research unit. Is it an offering of higher-level components, or an ironic critique of such libraries?


I'm the sole maintainer of the MMJ Depot at this point. First of all, thanks for taking the time to examine these tools; we rarely hear back from users about their experience (which is disheartening, considering how much work has gone into this particular tool set over time).

I wanted to mention that if you have any ideas of how to improve the depot (including ideas for new modules that we could include, or even lists of "required" or "essential" abstractions), we would greatly appreciate you elaborating on them and posting to either our issue tracker on github, or as a message to me personally. We are always interested in fixing our tools, and abiding by current coding conventions and best practices (and forming our own).

Possibly worth mentioning is that I'm working on a dynamic overview generation scheme that automatically builds an overview to get you a clear picture of what's in the package from the onset, which I hope eliminates the amount of digging curious users have to do.

Here's the depot on github, as a package:

I'm the sole maintainer of the MMJ Depot at this point.  First of all, thanks for taking the time to examine these tools; we rarely hear back from users about their experience (which is disheartening, considering how much work has gone into this particular tool set over time).

I wanted to mention that if you have any ideas of how to improve the depot (including ideas for new modules that we could include, or even lists of "required" or "essential" abstractions), we would greatly appreciate you elaborating on them and posting to either our issue tracker on github, or as a message to me personally.  We are always interested in fixing our tools, and abiding by current coding conventions and best practices (and forming our own).

Here's the depot on github, as a package:
https://github.com/CNMAT/CNMAT-MMJ-Depot

Nice to see these on Github; I wasn't aware of those before. It does seem like that's one thing the community is starting to coalesce around, and that's really helpful.

I have lots of old libraries from various places, and keeping track is a pain; this makes sharing and using other libraries so much less of a pain.

Nice to see these on Github; I wasn't aware of those before.  It does seem like that's one thing the community is starting to coalesce around, and that's really helpful.  

I have lots of old libraries from various places, and keeping track is a pain; this makes sharing and using other libraries so much less of a pain.


First of all, thanks for taking the time to examine these tools; we rarely hear back from users about their experience

I wanted to mention that if you have any ideas of how to improve the depot (including ideas for new modules that we could include, or even lists of “required” or “essential” abstractions), we would greatly appreciate you elaborating on them and posting to either our issue tracker on github, or as a message to me personally. We are always interested in fixing our tools, and abiding by current coding conventions and best practices (and forming our own).

my harsh response to your tools was meant as an example for the question the OP brought up.

the comment i was making here about someone elses software is about the same sort of reaction i get, too, when i show or send someone my software.

i see a bunch of nogos in your software, and if would send you my modules, you would also sit in front of something you´d probably also call an unorganized and half working mess.

mabye it has a bit to do with what roger said, we mainly build things for ourselves, based on our wishes and our thinking, on our operating system, our hardware, and eventually even for a certain kind of music style or installation.

i _want to share my stuff (and i think you, too), but i dont have a solution how to communicate these things. only one thing is sure: there will never be a documentation, all i can offer is online support.

Possibly worth mentioning is that I’m working on a dynamic overview generation scheme that automatically builds an overview

one thing i like is the look of your overview file (the one with the tabs for classes).

instead of an overview file i have made a bunch "extras" from where i just copynpaste my bpatchers to my working patch.

as an alternative, i have made a scripting module, which, when connected to [thispatcher], just scripts-new a bpatcher into root from a menu. it is somehow slick, and somehow the only thing you can do in MAC OS9 and/or Max 4.x, as there are no "prototypes".

but i must say, the amount of work i had to put in it is hard at the border, and it still doesnt work good in OSX because of some weird character limitation in menu in OSX.

i am really interested in discussing more ideas about presentation, help system, examples and these things, wwhich we need to share our stuff. because this is also my weak point.

but i first have to look again in the examples you provided. atm i can do that only with max runtime 5.x, so i can not comment the code, just what i feel could be missing or better.

oh yea, examples and introductions ... i think i´ve changed and restarted mine 3 times or so ... and they are still weird (at least thats what users say)

i am really interested in discussing more ideas about presentation, help system, examples and these things, wwhich we need to share our stuff. because this is also my weak point.
but i first have to look again in the examples you provided. atm i can do that only with max runtime 5.x, so i can not comment the code, just what i feel could be missing or better.

@ Peter: Thanks! Yeah; we've got a lot up there. Our downloads page basically links to the current release for each tool set. Don't forget to check out the infamous new odot externals, which can be found in our main externals download here:

...TBH, that's where a lot of my energy is going currently. We're migrating many things from the older depot tools over there that we find useful, into a supporting library of tools. The depot is more of a pedagogical catch-all for various collaborations we've had with students over the years, and lots of gems that need to be polished and updated. We'll get there. :)

@ Roman: Great; I'd be happy to continue the discourse off-list; feel free to contact me via the people page at CNMAT.

@ Peter: Thanks!  Yeah; we've got a lot up there.  Our downloads page basically links to the current release for each tool set.  Don't forget to check out the infamous new odot externals, which can be found in our main externals download here:
http://cnmat.berkeley.edu/downloads
...TBH, that's where a lot of my energy is going currently.  We're migrating many things from the older depot tools over there that we find useful, into a supporting library of tools.  The depot is more of a pedagogical catch-all for various collaborations we've had with students over the years, and lots of gems that need to be polished and updated.  We'll get there.  :)

@ Roman: Great; I'd be happy to continue the discourse off-list; feel free to contact me via the people page at CNMAT.
http://cnmat.berkeley.edu/people/j_lubow


Why aren't there more higher-level, modular, components like Beap?