On April 18, 2015 10:41:42 PM Dennis Schulmeister wrote: > Hi everybody, > > Just wanted to let you know that the precount feature seems to be > broken. MusE doesn't start recording and the transport buttons show an > undefined state. Esp. when the Stop button is pressed. Debug output is > > JACK: transition state PRECOUNT --> PLAY ? > > And respectively > > JACK: transition state PRECOUNT --> STOP ? > > Looking around, the issue is in Audio::start_rolling(). There's an > if-statement for the PRECOUNT state. At that point some values are > calculated but nothing else. Therefor the state newer changes to PLAY. > Seems like something's has been lost there at some point in time. > Commenting the code out (just the "if", not the "else") makes recording > start again. Albeit with no preroll, of course.
Robert I think all you did at one point was disable the GUI? Because it either wasn't working or interfered with something. I could swear long long ago it used to work. Do you remember? I have looked at the situation a few times while travelling through. I can't recall how it used to work, but if I recall correctly I concluded precount should make use of Jack's 'slow sync' feature, to hold up all clients and delay the Jack transport. Note there's a slow-sync timeout limit! It can be increased by a Jack call. And of course, you can't really hold up some external hardware midi device if it is the transport /master/ - it wants to roll right now. That device would have to have a precount feature. So things work best when MusE, with its midi features, is transport master. (Note: Dummy driver: When I added simulation of Jack Transport to our dummy driver I don't recall if I simulated Jack's 'slow sync' feature.) Instead of precount, another option is to reserve a 'setup' bar (or bars). I saw no reason to have MusE deem some bars 'special'. In other words, we simply remind users that it is quite common to use setup bars, and it is up to them how they use them. But we could allow users to adjust the first bar number from 1 to say, 0, -1, -2 and so on to help users mark that precious 'bar one'. A simple trick of numeric display on the timeline - like a sliding rule? Or more work? Like, allowing negative midi event times? I always use setup bars. They are simply blank and allow me a count. They also allow me to add /timed/ important setup messages at song start, such as device timing-sensitive sysexes (some settling time may be needed). (Note: Although my work on the Midi Instrument Editor allows Instrument Initialization Sequences, the 'Time' value of each sysex event is currently /ignored/ and these sequences are sent all in a burst. I am trying to find a way to send /timed/ messages at song load. Also the 'Time' value should be real time - not depend on tempo.) Coda? DC: Al Coda? Slightly OT: Might be interested to know I have an idea to use MusE Markers as 'Jump' commands (and therefore loops too). When looping there would be a 'repeat' number. This could also allow musical callable 'subroutines' if there are 'call' and 'return' markers. Jumping would be oh-so-handy for ignoring sections of a perhaps too-long song without cutting sections away. (Limited functionality of this type is/could be supported with our single pair of blue left and right cursors, instead of the markers.) > Another question: May it be that MusE is doing quite some strange > things to Sustain events? At the end Audio:start_rolling() there's some > special treatment for Sustain and during a quick test recording I had > many Sustain events lost. Didn't investigate further, though as I don't > know enough of the code and some of its reasoning. > > Dennis Yes the sustain is treated specially in MusE, it needs to be muted when the transport is stopped, its state remembered and then recalled when the transport rolls again, although the sustained notes themselves are not reactivated mid-note. Without this, sustain might remain stuck on, in stop mode. But it still allows you to play your keyboard, with sustain, in stop mode. Shouldn't be any major problems recording. Let me know. I do have problems sometimes when I switch patches from my keyboard. Sometimes when I switch back again the sustain is on for some reason. Note: Some problems with Midi Track 'Mute' and possibly with sustain were fixed in my midi_engine_fixes branch. To be finished and merged... Tim. ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
