Max/MSP projects for music pedagogy ?
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
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..
Mattijs
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.
I work on an EC project called i-Maestro which is using Max for music pedagogy, more info here...
www.i-maestro.org
oli
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
--
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
> 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.
Peter McCulloch
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
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.
Tim
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
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.
Mattijs
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.
On 14-juil.-07, at 18:05, Stefan Tiedje wrote:
> 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!
p
_____________________________
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).
--CJ
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 :)
Mattijs
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,
best Pere
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.
>
>
--
www.centuryofnoise.com
www.perevillez.com
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...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
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.
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
> 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.
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.
And with Jitter, you're almost
> there...
No, jitter is not an interface building toolkit.
Mattijs
>
> 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.
-CJ
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.
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
> 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...
> No, jitter is not an interface building toolkit.
Maybe you can create your own with jit.lcd...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
I have used a learning program created in MAX/MSP called 'Sybil' - stands for 'Synthesis by Interactive Learning' - developed by a team at Huddersfield University's Music Departement and used for teaching students- covers various aspects such as amplitude/ring modulation, frequency modulation, convolution etc...
Stuart
I'm currently building a sensor/software interface for creating music - geared towards children with cognitive and/or physical disabilities. The Manhattan New Music Project (owner of the software) plans to market this to schools and hospitals. Check out the screen shot and demo video here. We hired a graphic designer to do the pics for the front end. Max can look good.
Sharing patches for the good of education would be a must!
I'm also a teacher, and would like to use Max as an interactive way of learning an understanding music.
Cheers!
Not strictly a pedagogical tool, but I made a cut-down & more user-friendly version of one of my duo (me + harpist) performance patches. The context was some schools workshops based around our improvisation & the idea was to offer school kids (& anyone else) tools to do something a bit more off the wall than what they have in their standard DAWs and plugins, either live, or as a way of making materials (sound files) which could be brought back into a DAW for recording or composition projects.
It's at www.strangerainbow.co.uk
Just another example, and hardly anything difficult or impressive, but I created a standalone app for our vocal faculty to use in teaching singers. It incorporates a spectroscope~ and other tools to help with locating/developing singers' formants as well as recording lessons. It's the sort of thing anyone could hack together in Max in a few hours, but the teachers who use it say it's great for their purposes.
EH
One of the great things about using Max to create learning objects is that you can design the interface so that the user's attention is focused sequentially on the particular objective you want them to learn. Here are a few of the ones I've built, with more to come.
Take a look at this:
I think it fits your proposal.
I developed a synth tutorial, partly inspired by Sybil, for my masters and to aid with my teaching 16-18 year olds synthesis. It is available here:
While I am not a max expert by a long way, for me the main strength of max is the support available, but it's main weakness is how hard it is to make it sound as good as something like reaktor.
Hi everyone i am new here! Can you please tell me how could i make a real-time visual feedback singing tool to help my students exercise not only in songs that follow well-tempered scales but even songs that don;t follow this type of scales such as non-western micrototonal melodies?