David Olofson wrote: >If this does not demonstrate why I think NOTEPITCH is useful, I >frankly have no idea how to explain it, short of implementing both >alternatives in code.
i agree that the ability to discern different scales is handy indeed. but the only clean way to implement it is by going back to integer note numbers. this definitely is something plugins shouldn't have to care about i think. a reasonable approach is to leave the generation of correct pitch values to the sequencer -- if it does in fact support multiple tunings, it is bound to know how they map to pitch. no need to duplicate this knowledge in the api. or just go 12. / octave and meet me in politically incorrect westerners' hell -- i'll buy you a beer there if you manage to keep your future posts a little shorter. >Musical time *stops* when you stop the sequencer, which means that >So, for example, you can't change controls on your mixer, unless you >have the sequencer running. How logical is that in a virtual studio? this is a non-issue. if time stops but processing does not, all plugins keep processing events <= 'now', and the events they emit are stamped 'now'. that's how i do it anyway. you can proceed counting time in stopped state, but it's void of any meaning within transport time to do so, whether you're counting samples or beats. [bbt system] >IMHO, it should not be hardcoded into sequencers, and >definitely not into APIs. in fact i find myself happy without bbt mappings in the sequencer core, yes. others may have other needs. >You *may* know about the future along the sequencer's timeline, but >you do *not* know what the relation between audio time and musical >time will be after the end of the current buffer. you *will* know if you have a central tempo map -- which you have when you have a sequencer around, or instead confine yourself to one tempo, one beat, ie. the linear mapping case. >After you return from process(), event scheduled (be it with sample >count or musical time as a timestamp), someone might commit an edit >to the timeline, there could be a transport stop, or there could be a >transport jump. In either of those cases, you're in trouble. you're not. if you wouldn't check all queues on transport state change you don't understand enough of the workings of a sequencer yet. you may also want to synchronize changes to the tempo map and the loop points to be executed at cycle boundaries, which is how i am making these less invasive, but that's another story. >> > * Is there a need for supporting multiple timelines? >> >> this is a political decision, > >I disagree. It's also a technical decision. Many synths and effects >will sync with the tempo, and/or lock to the timeline. If you can >have only one timeline, you'll have trouble controlling these plugins >properly, since they tread the timeline pretty much like a "rhythm" >that's hardcoded into the timeline. to put this straight: there is no difference between musical time and 'real' time. the funny thing is if you're rooted in one view, the other appears non-linear. but the mapping between the two is an isomorphism no matter how you look at it. the trouble only starts when you have multiple mappings between musical and transport time, not when you have but one. back to the question, it is a decision that has deep technical implications, yes. but i insist it is largely political because few will ever need multiple concurrent 'timelines', and many will have to pay a price to enable them. i can only say i don't need them in musical practice, and they are uncommon enough to let those needing them do the maths themselves. one of the few things common to all musical culture seems to be that there is one predominant rhythmn, if there is rhythmn at all. >It doesn't seem too complicated if you think of it as separate >sequencers, each with a timeline of it's own... They're just sending >events to various units anyway, so what's the difference if they send >events describing different tempo maps as well? the point in having a sequencer is to have it become the central authority over tempo and time. the idea of sending tempo change events is, i'm afraid, another sign of some lack in understanding sequencers. and to make the point clear: you don't send tick events either, that's for synchronizing external equipment. you simply don't need it with a central time/tick/frame mapping. >Maybe it will be in most cases, but I can't see any real reasons why >you couldn't implement it as a reasonably normal plugin. there's absolutely no reason for the api to cover sequencers in plugin guise. it is a one-one relationship to the host. to be able to sequence every event in the network, you must assume the sequencer's access to the network to be about equivalent to the host's access. >Yes, but you still have to deal with tranport events. No big deal, >though; you just have to tell everyone that cares about them, so they >can adjust their internal "song position counters" at the right time. transport control is no event because it invariably involves a discontinuity in time, thus it transcends the very idea of an event in time. and plugins don't have an internal 'song position counter'. they rely on the host/sequencer to keep track of the passage of time, that's the whole point. tim