Hi, On Fri, 24 Jul 2009, Jakob Lund wrote: >> I haven't studied the speed of doing this, but off the cuff it would >> happen in linear time, O(N). Further, I expect that the number of >> events (N) in SeqScript will typically be 128 or less.[1] The operation >> would be to iterate through and (probably) compare an integer or two. >> >> So, no, it doesn't sound overly expensive. But, I can see where there's a >> possibility that I could be wrong about this. > > If every insertion is O(N), N insertions would be O(N^2), right? I realize
And N^2 insertions is O(N^4)?? :-P No. N insertions into a blank list would be less than N^2... somthing like N log N or something... > this may or may not be a problem, but It doesn't feel right, even for (a > pathological) worst case, in a real time context... We ought to have note > insertion in O(1) (or actually O(lgN) because they get sorted) ?! :-) We can add a bisection algorithm, which is considerably faster on a sorted list. > behaves) is that if a note plays on some instrument before a previous note on > that instrument has rung out, two copies of the sample will play, possibly > causing weird phaser effects.. IIRC, samples do not overlap... possibly causing weird clipping effects. :-) > Very good idea! Inputs hould have to use _either_ ticks or ms/frames, though, I was thinking ticks + ms for Inputs. > because given both, the seqScript wouldn't know how to sort properly. Also, > it (the seqScript) would have to keep two sorted lists (because the > relationship between the two might shift at any time), one by ticks and one > by ms/frame values. At output, the tick-based list would get serialized to > frames (up to nframes) and then merged into the other one. Nah, I think we could come up with a way to sort by tick + ms. If one of the critical factors (sample rate, tempo) changes, a resort might be necessary, though. Rather than resort... a "lookahead" algo. in the SeqScript might be necc. > Internally, the seqScript could map from B:b:t, that the song sequencer gives, > to a "running tick number" that could be used for sorting the list, and that > is easily translated into frame number, once the BPM is known. If SeqScript is doing B:b:t... why have a SongSequencer? Also, why should a raw MIDI Input be burdened with B:b:t? I'd like to keep SeqScript on simple terms... like just plain ticks (no bars or beats). Peace, Gabriel ------------------------------------------------------------------------------ _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
