[jmsl] absolute scheduling
jmsl at music.columbia.edu
jmsl at music.columbia.edu
Sat Sep 20 17:09:03 EDT 2008
Hmm... nice ideas both...
On 20-Sep-08, at 12:55 PM, jmsl at music.columbia.edu wrote:
> If you delete an event in the stream, how about replacing it with a
> placeholder with a duration? A "rest"? You're not really deleting
> time,
> you're just saying "don't play a note for this amount of time",
> which is a
> sort of musical event. So: keep the ParallelCollection, use a special
> constant (like -1) for note that indicates rest, and bob's your uncle.
>
The problem with the "rest" idea is that the event won't necessarily
be a rest, since a previous note might be sustaining underneath it.
More importantly, the removed event would no longer have a visible
notation in my score (which is actually in a Cocoa app), which could
get to be a bit of a nightmare.
> --rbt
>
>> -----Original Message-----
>> From: jmsl-bounces at music.columbia.edu
>> [mailto:jmsl-bounces at music.columbia.edu]On Behalf Of
>> jmsl at music.columbia.edu
>> Sent: Saturday, September 20, 2008 12:24 PM
>> To: jmsl at music.columbia.edu
>> Subject: Re: [jmsl] absolute scheduling
>>
>>
>> Hi J
>>
>> You are right. MusicShapes do not use absolute timestamps for
>> scheduling. If you remove one element, the MusicShape's remaining
>> elements jump forward in time. You might rewrite your "delete" to set
>> the amp or the picth to 0 to maintain duration but keep it silent.
>>
>> But cooler might be to redesign your model of a Track as a
>> ParallelCollection of MusicJobs, each responsible for a
>> single "note".
>> Each MusicJob's startDelay would correspond to the absolute
>> time since
>> the beginning of the Track. Then you could add and delete MusicJobs
>> without changing the overall sequence. You'd have to override
>> repeat()
>> to do something like:
>> getInstrument().play(playTime, 1, myData);
Yes, I think this is the way to go, and it's what I kind of had in
mind, since I was already using the ParallelCollection for my
playback... But, as stupid as it sounds, I'm a little lost as to how
to express the event itself in a MusicJob. From your description
above, it looks like the Instrument's play() method is what takes the
double[] array I was previously adding to my MusicShapes. Is that
correct?
Thanks for the help!
J.
>>
>>
>> How's that sound?
>>
>> Thanks
>> Nick Didkovsky
>>
>>
>>
>> jmsl at music.columbia.edu wrote:
>>> I'm trying to use jmsl to build a sequencing back-end for a
>>> composition app, but I'm having some real problems. I've based my
>>> design around ParallelCollection and MusicShape objects, but I'm
>>> having some troubles with the "duration" paradigm for scheduling
>>> events in MusicShape. Specifically, I want to have "tracks" with
>>> "events" at absolute, locked, locations in time. The problem I'm
>>> having is that, in a track with 4 events (for example),
>> when I delete
>>> event 2, the MusicShape moves events 3 and 4 back in time,
>> by virtue
>>> of the way the duration parameter works. I don't want that... If I
>>> remove an event, I just want to remove that event itself, without
>>> affecting any of the surrounding events. I could recalculate the
>>> durations, but that seems way over the top, to me...
>>> It seems like this should be easy, but for some reason I
>> can't wrap my
>>> head around how this would best be done.
>>>
>>> I would be enormously appreciative if somebody could just quickly
>>> describe the kind of data/object structure I'd best use for
>> this sort
>>> of sequencer design. I feel like it must still be a
>>> ParallelCollection, but I'm really not clear about how to populate
>>> it... At this point, my design uses a set of double[] arrays that
>>> represent my discrete events, and these events have a dimension for
>>> "metricPosition", which is an absolute location, in beats,
>> for the event.
>>>
>>> Any help very much appreciated.
>>>
>>> J.
>>>
>>> _______________________________________________
>>> jmsl mailing list
>>> jmsl at music.columbia.edu
>>> http://music.columbia.edu/mailman/listinfo/jmsl
>> _______________________________________________
>> jmsl mailing list
>> jmsl at music.columbia.edu
>> http://music.columbia.edu/mailman/listinfo/jmsl
>
> _______________________________________________
> jmsl mailing list
> jmsl at music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/jmsl
More information about the jmsl
mailing list