RE: [analogue-sequencer] p3 v4 controller weirdness
2007-06-22 by implode7@comcast.net
duh..... ok. Obviously. I should start with track 8 and work my way backwards I think, since otherwise I'm always thinking in the wrong order. I did know that the push only sends the value, but since stuff was happening, I spaced on the numerical order thing. It's funny - I never used to use push - I always used grab, until it occurred to me that you can do stuff with push that you can't (at least not easily - there's usually SOME way to do practically anything on the p3) with grab. Then I just forgot about this consideration. If I understand you correctly below, you didn't address the issue that the push command also seemed to push the events on auxes 3 and 4, or at least attempt to. Or maybe you did, but I didn't understand it. Is there any way to reverse the order of the tracks? 1 to 8, 2 to 7, 3 to 6, etc, in a timely fashion? I'm at work, and bad at abstracting this stuff, but I have stuff in all of the tracks, so if I wanted to swap a pair or two, that becomes a little awkward, I think? No biggie though - this was mostly a 'mess with new synth' sequence anyways... btw - I haven't responded to the new memory post you made yet since I've always spent all of my money, and don't want to commit to this and then not have the money when they are available. Do you have a time frame on it? will this be installable by someone who is rather incompetent at hardware diy stuff?
Show quoted textHide quoted text
-------------- Original message ---------------------- From: "Colin Fraser" <colin@sequentix.com> > Hi Gene, > > > I�m sure that as soon as I ask this I�ll figure out that I�m > > overlooking > > something simple, but I�m puzzled right now. > > You were overlooking something simple - a bug ;-) > Well, mostly. > > When you use the push, swap or grab events, you need to remember two things > - the tracks are processed in numerical order, and push/swap/grab only > changes the values, not the aux assignments (though you maybe knew that > already) > > So when you were pushing a value for aux B from track 6 to track 1, it was > already too late - track 1's events had been processed, so the change of > value made by the event on track 6 should have not had any effect. > The bug (which has probably been around for a long time...) is that the > change of value did have an effect - it fooled the CC generating code into > thinking there was a valid CC value in aux B on track 1. > There's an enable bit in the value for an aux on a given step that is > cleared when the event assigned to that aux is processed. > If the active bit is still set once event handling is complete, the value is > treated as a CC instead. > The 'push' of the value from a later track was making the value for the step > in track 1 active again after it had been cleared when the event was > processed, so it was treated as a CC. > Internally, 'xpose by track n' is event number 24, which is where CC #24 > came from. > I'll look at fixing this, though it shouldn't really be a problem, since > pushing/grabbing/swapping from a higher track number does not have any > effect. > > Best regards, > Colin Fraser > Sequentix Music Systems Ltd > http://www.sequentix.com > > > [Non-text portions of this message have been removed]