I wish I could help you with the software bugs and reccomendations, but I haven’t gotten to use my Midi Murf with the Software yet, and I am still awaiting its return from factory repair.
I’m going to buy one sometime soon, but my logic would tell me if you’ve stopped sending clock, the MuRF should probably stop too.
If your DAW-based project stopped, then wouldn’t the outgoing audio also halt? And if you were playing live with your sequence, would you not extend the coda in software to keep playing along?
First I’d like to say that it’s positively zzymzzy that you ask us questions like this.
I’ve given this a lot of thought and keep ending up at:
If the sound source stops when you send a MIDI Stop command, then it doesn’t
matter if you don’t stop the MuRF. It will still be silent.
If the sound source is coming from something that you’re manually playing along
with a sequenced sound source, you have the ability to stop your instrument or keep
playing afterwards. If you stop playing at the same time, it doesn’t matter if you
don’t stop the MuRF. It will still be silent.
But, if you wanted to keep playing your non-sequenced instrument through the
MuRF as a post-sequence outro, (think Prince’s “The Beautiful Ones”) you’d hate it
if the MuRF suddenly stopped.
If you really needed the MuRF to stop you could make it go to Pattern 1 on the
last beat of the last measure of the sequence. This would allow you to be very specific
as to what timbral shape it stopped at. Or you could send a Bypass message at the end
if you wanted the MuRF gone when the sequence stopped.
The more embarrassing thing the MuRF could do in a live performance, between
suddenly stopping or suddenly not stopping, (sorry, I’ve read too much Hitchhikker’s)
is the former.
In summary: I want my performances to have the option to keep going if so moved.
That presumes that I’ll know, the night before the big show, precisely
how long I’m going improvise at the end of that song.
Can you imagine being on fire on stage, and you’re taking the song’s
ending to an entirely new place and then, you suddenly realize that
you now have to calculate how many seconds you have left before your
sequence brings your MuRF to a crashing halt?
When I finally finish plucking (or keying, or singing, or EtherWaving)
into the MuRF, no one will be able to hear that the MuRF is still going.
(I’m the guy who voted “other” because even I can’t view the poll results unless I vote)
Erick, I can’t really make it an option to do A or B because the Moogerfooger’s UI is so limited… It’s about a million times easier to just implement one behavior. Which means I can’t please everybody. Which means, I definitely want feedback and discussion before deciding arbitrarily how the gear will behave for everybody down thru the ages. It’s a big responsibility.
So, thanks for the help, y’all! I definitely appreciate it.
My whole point was exactly the one you articulated.
I don’t have my murf and when I did, didn’t have the abillity o try sequences. I would like to help but I can’t just throw a vote out there and say "Well have them stop with Midi Clock or have them continue with Midi CLock. Since its either or, I asked the question and Im glad you threw your cents in.
Usually, when butting my head against something it’s because something’s
going to be taken away and when the people voting to take it away are asked,
the reason is usually that it’s the way it “should be”.
Example:
On workstations, like the Kurzweil, I often assign the same CC# to
several controllers. For example, I have my ModWheel on CC#1 for
Leslie Speed and then make one of my footswtiches also send CC#1.
This way I can have Leslie Fast “stick” by leaving the ModWheel up
or I can pulse it via the footswitch. Even if the ModWheel is up,
I can make the Leslie slow down by tapping the footswitch (since
MIDI always does the last thing you tell it.)
But another keyboard company I beta-tested for kept saying, “You can’t
have two controllers sending the same CC#.” And so, they do not have
CC#1 listed as a choice for their footswitch’s CC#.
Perhaps the obvious solution is to have two versions of the firmware
It depends how easy it is to work into the code. If we’re talking a complete re-write each time then maybe not (makes no sense to maintain two versions). But if it’s a few lines in C or assembler which could be changed and compiled, then maybe.
