Cheng Chien-Wen

I use Max/MSP for interactive performance for years. But recently people from music pedagogy field asked me if Max/MSP can be used for music pedagogy. I believe such a project is quite possible, but I never saw people did this. I am trying to convince some pedagogy researchers to believe that Max/MSP is not only good for compositional purposes, but may also be used to create music education programs.

Could any one provide some ideas or examples that use Max/MSP to program a software dedicated to music education ?

I use Max/MSP for interactive performance for years. But recently people from music pedagogy field asked me if Max/MSP can be used for music pedagogy. I believe such a project is quite possible, but I never saw people did this. I am trying to convince some pedagogy researchers to believe that Max/MSP is not only good for compositional purposes, but may also be used to create music education programs. 

maxmsp-projects-for-music-pedagogy

Maybe I miss the point but don't you think any project that involves music software (including pedagogy projects) could be done in maxmsp just like it could be done in any other programming language?

So I'd say just make a list of all available music pedagogy projects that use computers and software (including those that are not done in max) and hand that over to the researchers..

Quote: Cheng Chien-Wen wrote on Fri, 13 July 2007 16:35

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

> I use Max/MSP for interactive performance for years. But recently people from music pedagogy field asked me if Max/MSP can be used for music pedagogy. I believe such a project is quite possible, but I never saw people did this. I am trying to convince some pedagogy researchers to believe that Max/MSP is not only good for compositional purposes, but may also be used to create music education programs. 

> Could any one provide some ideas or examples that use Max/MSP to program a software dedicated to music education ?

Quote: Cheng Chien-Wen wrote on Fri, 13 July 2007 16:35
----------------------------------------------------
> I use Max/MSP for interactive performance for years. But recently people from music pedagogy field asked me if Max/MSP can be used for music pedagogy. I believe such a project is quite possible, but I never saw people did this. I am trying to convince some pedagogy researchers to believe that Max/MSP is not only good for compositional purposes, but may also be used to create music education programs. 
>
> Could any one provide some ideas or examples that use Max/MSP to program a software dedicated to music education ?
>
> Thanks.  
>
> Chien-Wen
----------------------------------------------------


Sure, you can build things like piano tutors, eartraining exercises, compositional aids, etc in Max. if that's what you mean.

Sure, you can build things like piano tutors, eartraining exercises, compositional aids, etc in Max.  if that's what you mean.


I work on an EC project called i-Maestro which is using Max for music pedagogy, more info here...

> Could any one provide some ideas or examples that use Max/MSP to

> program a software dedicated to music education ?

I bet the amount of work necessary to create an ear traing program, just 

as example, would be less than a 1/10th compared to any other 

The reason is simple. For educational programs the user interface is 

almost the only thing which is difficult, anything else should be 

straight forward. But if you designe a UI in Max, its already a 

I can't imagine a better tool to do educational music programs than Max. 

BIG advantage, the users don't need to buy Max, it will run as 

Cheng Chien-Wen schrieb:
> Could any one provide some ideas or examples that use Max/MSP to
> program a software dedicated to music education ?

I bet the amount of work necessary to create an ear traing program, just 
as example, would be less than a 1/10th compared to any other 
programming language.
The reason is simple. For educational programs the user interface is 
almost the only thing which is difficult, anything else should be 
straight forward. But if you designe a UI in Max, its already a 
functional program...

I can't imagine a better tool to do educational music programs than Max. 
BIG advantage, the users don't need to buy Max, it will run as 
standalone or in MaxPlay...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

> I bet the amount of work necessary to create an ear traing program, 

> just as example, would be less than a 1/10th compared to any other 

> The reason is simple. For educational programs the user interface is 

> almost the only thing which is difficult, anything else should be 

> straight forward. But if you designe a UI in Max, its already a 

While I agree with the parent, if, for some reason, you wanted to look 

at another language, I would look at JMSL. Requires programming in 

Java, but has lots of nice perks. For instance, your program can run 

as an applet. Also, JMSL provides full notation built-in, which is 

If you run the programs as applets, there's only the cost of a license 

for the host computer (to compile the applet), so it's very economical. 

Also, site licenses are very reasonable. Downsides: you'll need to 

learn Java, and it's not as easy to pick up as Max. JMSL does play 

well with Max, so it's something nice to have in the toolbox.

> I bet the amount of work necessary to create an ear traing program, 
> just as example, would be less than a 1/10th compared to any other 
> programming language.
> The reason is simple. For educational programs the user interface is 
> almost the only thing which is difficult, anything else should be 
> straight forward. But if you designe a UI in Max, its already a 
> functional program...

While I agree with the parent, if, for some reason, you wanted to look 
at another language, I would look at JMSL.  Requires programming in 
Java, but has lots of nice perks.  For instance, your program can run 
as an applet.  Also, JMSL provides full notation built-in, which is 
very convenient.

If you run the programs as applets, there's only the cost of a license 
for the host computer (to compile the applet), so it's very economical. 
  Also, site licenses are very reasonable.  Downsides: you'll need to 
learn Java, and it's not as easy to pick up as Max.  JMSL does play 
well with Max, so it's something nice to have in the toolbox.

Quote: Stefan Tiedje wrote on Sat, 14 July 2007 18:05

Haha, this would the most important reason for me not to use Max; interface design is definitly one of Max' weakest points.

Quote: Stefan Tiedje wrote on Sat, 14 July 2007 18:05
----------------------------------------------------

> The reason is simple. For educational programs the user interface is 
> almost the only thing which is difficult, anything else should be 
> straight forward. 

Haha, this would the most important reason for me not to use Max; interface design is definitly one of Max' weakest points. 

The question is usually--what do you need students to do? Example--a colleague was looking for some audio analysis tools for working with his voice students, so I made him a simple standalone with some options for various views, multiple inputs, etc. Was very easy in Max.

The question is usually--what do you need students to do?  Example--a colleague was looking for some audio analysis tools for working with his voice students, so I made him a simple standalone with some options for various views, multiple inputs, etc.  Was very easy in Max.

Not sure why (GUI) it should be one of Max's weakest points?

I have created some silly simple stuff for students, (which Im happy to

upload if there is a space somewhere) in which interface simplicity is one

For most educational projects, the available gui elements in Max should be

fine. They might not be current, but you can always use a number of

supporting languages and programming environments (Flash is just one).

> Quote: Stefan Tiedje wrote on Sat, 14 July 2007 18:05

> ----------------------------------------------------

> > The reason is simple. For educational programs the user interface is

> > almost the only thing which is difficult, anything else should be

> Haha, this would the most important reason for me not to use Max;

> interface design is definitly one of Max' weakest points.

> Hard- and software for interactive audiovisual sampling

Not sure why (GUI)  it should be one of Max's weakest points?

I have created some silly simple stuff for students, (which Im happy to
upload if there is a space somewhere) in which interface simplicity is one
of the most essential requirements.

For most educational projects, the available gui elements in Max should be
fine. They might not be current, but you can always use a number of
supporting languages and programming environments (Flash is just one).

On 15/07/07, Mattijs Kneppers  wrote:
>
>
> Quote: Stefan Tiedje wrote on Sat, 14 July 2007 18:05
> ----------------------------------------------------
>
> > The reason is simple. For educational programs the user interface is
> > almost the only thing which is difficult, anything else should be
> > straight forward.
>
> Haha, this would the most important reason for me not to use Max;
> interface design is definitly one of Max' weakest points.
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>

-- 
www.centuryofnoise.com
www.perevillez.com

I think we're talking about different things. For students with a a technical background that have to learn how to work with max, the current set of gui elements is fine. But when you need a program that has to be used by children (which I suppose is what Cheng Chien-Wen is after), you need a very different approach, i.e. a 'real' interface.

Quote: pvillez@gmail.com wrote on Mon, 16 July 2007 12:46

> Not sure why (GUI) it should be one of Max's weakest points?

> I have created some silly simple stuff for students, (which Im happy to

> upload if there is a space somewhere) in which interface simplicity is one

> For most educational projects, the available gui elements in Max should be

> fine. They might not be current, but you can always use a number of

> supporting languages and programming environments (Flash is just one).

Quote: pvillez@gmail.com wrote on Mon, 16 July 2007 12:46
----------------------------------------------------
> Not sure why (GUI)  it should be one of Max's weakest points?
>
> I have created some silly simple stuff for students, (which Im happy to
> upload if there is a space somewhere) in which interface simplicity is one
> of the most essential requirements.
>
> For most educational projects, the available gui elements in Max should be
> fine. They might not be current, but you can always use a number of
> supporting languages and programming environments (Flash is just one).
>
> regards Pere
>


Pere, I'd definitely like to see your patches. You can upload them to this thread in the forum. 

Pere, I'd definitely like to see your patches.  You can upload them to this thread in the forum. 


On 14-juil.-07, at 18:05, Stefan Tiedje wrote:

>> Could any one provide some ideas or examples that use Max/MSP to

>> program a software dedicated to music education ?

I did a small ear training software for guitarists last summer. It took 

me half a day to code the logic in Max, but a couple of weeks for the 

interface, in JavaScript. And the UI is far for being nice yet!

Centre de Recherches et de Formation Musicales de Wallonie

> Cheng Chien-Wen schrieb:
>> Could any one provide some ideas or examples that use Max/MSP to
>> program a software dedicated to music education ?
>
> I bet the amount of work necessary to create an ear traing program, 
> just as example, would be less than a 1/10th compared to any other 
> programming language.
> The reason is simple. For educational programs the user interface is 
> almost the only thing which is difficult, anything else should be 
> straight forward.

I did a small ear training software for guitarists last summer. It took 
me half a day to code the logic in Max, but a couple of weeks for the 
interface, in JavaScript. And the UI is far for being nice yet!

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie
http://users.skynet.be/crfmw/max


I definitely second that, its ability to produce prototypes rapidly and to store / manage data is tough to beat. Plus changes can generally be made easily and quickly -- this makes it possible for one's research subjects (the anticipated end-user population) to be actively involved in the design process (by providing feedback or feature requests that can be implemented right away).

Regarding the interface, I'll agree it takes some work to pretty things up from the "quick and dirty" objects, but compared to creating one's own objects it's orders of magnitude easier and the objects are much more functional than what anyone besides real programming experts could reasonably do (can you easily code something like a matrixctrl in C? even if you can, how long would it take??)

With experimentation one can come up with some pretty good alternatives to the "quick and dirty" gray objects that most people seem to use. Of course, this would only be important if the appearance is important, which it isn't for many projects.

There's also the jsui object, which through some javascript one can make pretty much any interface designs one wants (which can inclue transparency and has a number of key-mouse combinations built-in). The downsides are the learning time for the coding and slowed interface performance due to drawing (though turning off fsaa improves this considerably).

I definitely second that, its ability to produce prototypes rapidly and to store / manage data is tough to beat. Plus changes can generally be made easily and quickly -- this makes it possible for one's research subjects (the anticipated end-user population) to be actively involved in the design process (by providing feedback  or feature requests that can be implemented right away).

Quote: seejayjames wrote on Tue, 17 July 2007 15:57

> I definitely second that, its ability to produce prototypes rapidly and to store / manage data is tough to beat. Plus changes can generally be made easily and quickly -- this makes it possible for one's research subjects (the anticipated end-user population) to be actively involved in the design process (by providing feedback or feature requests that can be implemented right away).

I agree, 'jammability' is definitly one of max' strongest points compared to any other programming language. Together with the fact that it provides the only complete, self-compatible and (mostly) consistent library for audio, video and hardware interfacing that I know of.

> Regarding the interface, I'll agree it takes some work to pretty things up from the "quick and dirty" objects, but compared to creating one's own objects it's orders of magnitude easier and the objects are much more functional than what anyone besides real programming experts could reasonably do (can you easily code something like a matrixctrl in C? even if you can, how long would it take??)

I think the point is that programming a 'real' interface will always require programming experience. But from a programmers perspective, Max is not good at it either. Of course it must be mentioned that Max was never meant to be good at this in the first place.

> With experimentation one can come up with some pretty good alternatives to the "quick and dirty" gray objects that most people seem to use. Of course, this would only be important if the appearance is important, which it isn't for many projects.

.. indeed, depending on the project. But not only appearance, also usability.

A music pedagogy project is of course a big candidate for a tool that only uses a hardware interface, no computer screen.

> There's also the jsui object, which through some javascript one can make pretty much any interface designs one wants (which can inclue transparency and has a number of key-mouse combinations built-in). The downsides are the learning time for the coding

exactly, which makes you.. a programmer :)

Quote: seejayjames wrote on Tue, 17 July 2007 15:57
----------------------------------------------------
> I definitely second that, its ability to produce prototypes rapidly and to store / manage data is tough to beat. Plus changes can generally be made easily and quickly -- this makes it possible for one's research subjects (the anticipated end-user population) to be actively involved in the design process (by providing feedback  or feature requests that can be implemented right away).

>
> Regarding the interface, I'll agree it takes some work to pretty things up from the "quick and dirty" objects, but compared to creating one's own objects it's orders of magnitude easier and the objects are much more functional than what anyone besides real programming experts could reasonably do (can you easily code something like a matrixctrl in C? even if you can, how long would it take??)

>
> With experimentation one can come up with some pretty good alternatives to the "quick and dirty" gray objects that most people seem to use. Of course, this would only be important if the appearance is important, which it isn't for many projects.

.. indeed, depending on the project. But not only appearance, also usability. 

>
> There's also the jsui object, which through some javascript one can make pretty much any interface designs one wants (which can inclue transparency and has a number of key-mouse combinations built-in). The downsides are the learning time for the coding 

Ok , sure will do that. One is an app that displays lissajous of harmonics.

I will put it on a server tommorow when Im back in the office,

> Pere, I'd definitely like to see your patches. You can upload them to

Ok , sure will do that. One is an app that displays lissajous of harmonics.
I will put it on a server tommorow when Im back in the office,

On 16/07/07, Dan Winckler  wrote:
>
> Pere, I'd definitely like to see your patches.  You can upload them to
> this thread in the forum.
>
>

No it's one of its strongest, don't mix this up with the look of the

interface. To make it shine like the last fashion of blinking skins, you

might be correct, but that's the last and least important point. Though

if you're going to sell your software, the look might be more important

Don't get me wrong, I like fancy looks, but I am so pissed off when I

come across shiny software which has bad ergonomics.

In Max you can just test while patching and adapt to the real needs

Of course Max is not made for creating visual games, but C isn't either...

In any language you need to rely on libraries, original, 3rd party or 

your own, to do the more complex stuff. And with Jitter, you're almost 

Mattijs Kneppers schrieb:
> Haha, this would the most important reason for me not to use Max;
> interface design is definitly one of Max' weakest points.

No it's one of its strongest, don't mix this up with the look of the
interface. To make it shine like the last fashion of blinking skins, you
might be correct, but that's the last and least important point. Though
if you're going to sell your software, the look might be more important
than the functionality of course... ;-)
Don't get me wrong, I like fancy looks, but I am so pissed off when I
come across shiny software which has bad ergonomics.
In Max you can just test while patching and adapt to the real needs
immediately...
Of course Max is not made for creating visual games, but C isn't either...
In any language you need to rely on libraries, original, 3rd party or 
your own, to do the more complex stuff. And with Jitter, you're almost 
there...

Quote: Stefan Tiedje wrote on Wed, 25 July 2007 12:23

> > Haha, this would the most important reason for me not to use Max;

> > interface design is definitly one of Max' weakest points.

> No it's one of its strongest, don't mix this up with the look of the

No ;) I have to hold on to this point, it's one of the weakest. I don't care about shiny looks but I do care about functional design.

If you need an interface for people that have nothing to do with the programming of patches, max has a lot of restrictions. You need separate screen area's in your patch that change their content independently (note bpatchers and the problems you get when you stack them). You want your interface to update as often as possible BUT at a lower priority than the rest of the patch (typically video processing). You need custom gui elements (jsui is really not fast enough). Think about the weird spaces in your interfaces and the untidyness that results from unlocking and scrolling the patch every time you need to change some hidden objects that surround the visible ones. etc etc.

So, no, max is not good at interfaces, even when we are not talking about rounded corners, embossed ridges and gradients (that I dislike, personally). And again, I don't think max in the current form was ever meant to build interfaces for non-maxers.

> To make it shine like the last fashion of blinking skins, you

> might be correct, but that's the last and least important point. Though

> if you're going to sell your software, the look might be more important

> than the functionality of course... ;-)

> Don't get me wrong, I like fancy looks, but I am so pissed off when I

> come across shiny software which has bad ergonomics.

> In Max you can just test while patching and adapt to the real needs

> Of course Max is not made for creating visual games, but C isn't either...

> In any language you need to rely on libraries, original, 3rd party or 

> your own, to do the more complex stuff.

That's right. Seeing that max is a collection of highly consistent libraries for audio and video I guess an interface building toolkit would fit in nicely. Only it doesn't exist yet.

No, jitter is not an interface building toolkit.

Quote: Stefan Tiedje wrote on Wed, 25 July 2007 12:23
----------------------------------------------------
> Mattijs Kneppers schrieb:
> > Haha, this would the most important reason for me not to use Max;
> > interface design is definitly one of Max' weakest points.
>
> No it's one of its strongest, don't mix this up with the look of the
> interface. 

No ;) I have to hold on to this point, it's one of the weakest. I don't care about shiny looks but I do care about functional design. 

If you need an interface for people that have nothing to do with the programming of patches, max has a lot of restrictions. You need separate screen area's in your patch that change their content independently (note bpatchers and the problems you get when you stack them). You want your interface to update as often as possible BUT at a lower priority than the rest of the patch (typically video processing). You need custom gui elements (jsui is really not fast enough). Think about the weird spaces in your interfaces and the untidyness that results from unlocking and scrolling the patch every time you need to change some hidden objects that surround the visible ones. etc etc. 

> To make it shine like the last fashion of blinking skins, you
> might be correct, but that's the last and least important point. Though
> if you're going to sell your software, the look might be more important
> than the functionality of course... ;-)
> Don't get me wrong, I like fancy looks, but I am so pissed off when I
> come across shiny software which has bad ergonomics.
> In Max you can just test while patching and adapt to the real needs
> immediately...
> Of course Max is not made for creating visual games, but C isn't either...
> In any language you need to rely on libraries, original, 3rd party or 
> your own, to do the more complex stuff. 

And with Jitter, you're almost 
> there...

>
> Stefan
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
>
>
----------------------------------------------------


I can definitely relate to the untidyness factor, it seems to come from trying to strike that balance between having your "processing" objects available while developing versus having them in a subpatch. But that's not really the "fault" of Max, it's simply different aesthetics and organization. There's the benefit of code-based, as everything is hidden. However it's generally a lot tougher and non-intuitive for most people to learn and to read what's happening since it's linear and text-based, with a heck of a lot of restrictions and rules on syntax, etc. There are of course rules in Max too, but they're different... and usually don't require high levels of detail-oriented proofreading.

I have to say I'm on Max's side with the interface question -- you can whip up pretty amazing stuff quickly, and if you want to make it professional-looking you can through a variety of means (some of which may require coding, I'll admit). The jsui *is* too slow, but again, where is the fault....? Soon processors will certainly catch up and things will be smoother, as will jitter elements, etc.

Perhaps a stock series of prototypes / templates for the interface objects would be nice to include in future releases, so that users (especially new ones) get an idea of what potential appearance varieties are possible. I have the feeling that not many people get far past the standard grey objects, which are functional but do look rather dismal (though they are a good choice as "standard" objects and I can appreciate why they look that way).

I can also see a benefit to having additional subpatches in the help files that deal with appearance -- there are some already, but often they don't cover everything. It would be nice to see what all those messages do for your objects without having to manually put them all in.

Finally -- through scripting there's *so* much one can do, and dang if it's not super-easy, quick, and intuitive compared to many environments... the commands are right there instead of buried in some code somewhere... gotta love that. I'd like to see some more examples of scripting-in-action in the help and tutorial files, I think there's a lot of possibilities that many users don't really know about or know how best to utilize.

Perhaps a stock series of prototypes / templates for the interface objects would be nice to include in future releases, so that users (especially new ones) get an idea of what potential appearance varieties are possible. I have the feeling that not many people get far past the standard grey objects, which are functional but do look rather dismal (though they are a good choice as "standard" objects and I can appreciate why they look that way). 

> If you need an interface for people that have nothing to do with the 

> programming of patches, max has a lot of restrictions. You need 

> separate screen area's in your patch that change their content 

Yeah, its bad for bad interface design ;-) Changing contents isn't a

good design idea, but its easily possible. I heard that there are still 

some redraw bugs with bpatcher, but we're not talking about bugs here, 

> You want your interface to update as often as possible BUT at a lower

> priority than the rest of the patch (typically video processing). You

> need custom gui elements (jsui is really not fast enough).

There is Jitter... And jsui is fast enough for user interface elements.

Video isn't part of user interaction in general, maybe in your specific

needs, but tell me which tool does it better? Especially for the topic

> Think about the weird spaces in your interfaces and the untidyness

> that results from unlocking and scrolling the patch every time you

> need to change some hidden objects that surround the visible ones.

This is something a non Max user will never touch and see... not a point.

> And again, I don't think max in the current form was ever meant to

Look at Radial, Pluggos and the fact that there was a MaxPlay and 

standalones from the very beginning. This should proove your statement 

wrong. I am sure that a product like Radial would be coded differently 

if Max wouldn't be an apropriate tool for that.

Again I am not talking about video games...

> That's right. Seeing that max is a collection of highly consistent 

> libraries for audio and video I guess an interface building toolkit 

> would fit in nicely. Only it doesn't exist yet.

But I am using it since more than 15 years... The strength of Max is 

that it's different than any other interface building toolkits. Maybe 

you're confused that it doesn't distinguish between UI and functional 

parts. But that's your responsibility, if you want to seperate them, 

just do it, it's not required and usually even not such a good idea...

> No, jitter is not an interface building toolkit.

Maybe you can create your own with jit.lcd...

Mattijs Kneppers schrieb:
> If you need an interface for people that have nothing to do with the 
> programming of patches, max has a lot of restrictions. You need 
> separate screen area's in your patch that change their content 
> independently.

Yeah, its bad for bad interface design ;-) Changing contents isn't a
good design idea, but its easily possible. I heard that there are still 
some redraw bugs with bpatcher, but we're not talking about bugs here, 
and they never affected my UI designs...

> You want your interface to update as often as possible BUT at a lower
> priority than the rest of the patch (typically video processing). You
> need custom gui elements (jsui is really not fast enough).

There is Jitter... And jsui is fast enough for user interface elements.
Video isn't part of user interaction in general, maybe in your specific
needs, but tell me which tool does it better? Especially for the topic
of this thread, all you need is there...

> Think about the weird spaces in your interfaces and the untidyness
> that results from unlocking and scrolling the patch every time you
> need to change some hidden objects that surround the visible ones.
> etc etc.

> And again, I don't think max in the current form was ever meant to
> build interfaces for non-maxers.

Look at Radial, Pluggos and the fact that there was a MaxPlay and 
standalones from the very beginning. This should proove your statement 
wrong. I am sure that a product like Radial would be coded differently 
if Max wouldn't be an apropriate tool for that.
Again I am not talking about video games...

> That's right. Seeing that max is a collection of highly consistent 
> libraries for audio and video I guess an interface building toolkit 
> would fit in nicely. Only it doesn't exist yet.

But I am using it since more than 15 years... The strength of Max is 
that it's different than any other interface building toolkits. Maybe 
you're confused that it doesn't distinguish between UI and functional 
parts. But that's your responsibility, if you want to seperate them, 
just do it, it's not required and usually even not such a good idea...

Max/MSP projects for music pedagogy ?