[jmsl] Articulation request

jmsl at music.columbia.edu jmsl at music.columbia.edu
Mon Jul 7 13:01:46 EDT 2008


Hello Georg

I experimented with music fonts at one point. Mike Winter had done 
gorgeous rendering with them in Java under OSX, which was the carrot. It 
worked on the Mac but not on Windows (see the JMSL list thread with the 
subject "Maestro music font and Java"). Maybe the problem has 
disappeared with recent Java updates (Windows rendered rectangles 
instead of the symbols)... it's worth running some tests again.

I agree it would look attractive to use a real music font in both JMSL 
and MaxScore, but as you've surmised, it would indeed require a deep 
rewrite of how JMSL does its score rendering.  I am not closed to the 
idea but I got discouraged by the initial experiments and did not pursue 
it further.

I like the idea of JMSL's scheduler being driven by an external clock.  
JMSL has a MusicClock class that it consults to determine how long music 
threads should sleep, for example. Various implementations of MusicClock 
exist already, and setting the clock is straightforward (JMSL.clock = 
new DethClock() for example). I like the idea of being able to drive 
JMSL the new Max5 transport features. Driving with a SMPTE source would 
be useful as well.

Thanks
Nick


jmsl at music.columbia.edu wrote:
> What would make MaxScore more versatile is if the object wasn't 
> sending out drawing commands but, instead, higher-level engraving 
> commands that are being interpreted in the Max environment.
>
> For instance, instead of sending several linesegment messages 
> representing a clef, MaxScore could send out "clef treble x y" (or 
> "clef 0 x y" to be more consistent with the xml ocde). In Max, these 
> messages could then either be interpreted as a series of linesegments 
> or as a clef symbol, be it Emmenthaler or Maestro or whatever font one 
> prefers).
>
> Using more high-level or abstract "descriptors" it would be much 
> easier to customize MaxScore and add more symbols to the repertoire. 
> It would make MaxScore also more efficient as fewer data would have to 
> be piped to the Max environment. Being free to interpret higher-level 
> data, one could control playback  as well and, thus, interpret a trill 
> or tremolo, etc. This is how the promising new engraving software 
> Notion (http://www.notionmusic.com/) works.
>
> One other feature that I'd like to put on the wish list is flexible 
> tempo. Max5 incorporates a set of new objects centered around 
> transport (http://www.cycling74.com/products/maxuptiming). It would 
> great if an external clock could optionally control the playback speed 
> of a MaxScore sequence.
>
> I understand that implementing all this, implies a major modification 
> of JScore's architecture.
>
> Georg
>
> ***************************************************
> Phone:
> +49-40-428482-763 (w)
> +49-40-23517610 (h)
> +49-172-787-4214 (m)
> +49-40-428482-770 (f)
>
> e-mail: georg.hajdu at hfmt-hamburg.de
> e-mail: georghajdu at mac.com
> http://www.georghajdu.de/index.html
> http://www.quintet.net/
> http://mmm.hfmt-hamburg.de
> ****************************************************
>
>
> On Jun 30, 2008, at 6:01 PM, jmsl at music.columbia.edu wrote:
>
>> For instance, I could imagine in MaxScore using a custom articulation 
>> to trigger a Max event while the score is playing, or a special 
>> articulation for infinite sustain until the user chooses to continue 
>> playing.
>
> _______________________________________________
> jmsl mailing list
> jmsl at music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/jmsl


More information about the jmsl mailing list