[jmsl] absolute scheduling

[jmsl at music.columbia.edu]

That's what I meant with "You might rewrite your "delete" to set the amp 
or the pitch to 0 to maintain duration but keep it silent. "
But Robert did a better job of explaining it than I did.
Thanks
Nick

jmsl at music.columbia.edu wrote:
> 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
>
> _______________________________________________
> jmsl mailing list
> jmsl at music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/jmsl