Mute Tool weirdness.....

[MikeInBoston]

I love the fact that you can now mute MIDI notes. This deserves a big HOOORAY! What's weird is that muted notes show up in Quickscribe. What's with that? I would expect that deactivated notes would also be "turned off" when displaying notation.

What do you think?

Mike

[wvandyck]

It would be handy to have some visual indication of muted notes in QS.
Right now, they look like normal notes.

You can use the Edit>Search>New Search "Select Similar (by type)" with "Based settings on current selection" in the MIDI editor to find all the muted notes to delete them when ready.

[Shooshie]

I love the fact that you can now mute MIDI notes. This deserves a big HOOORAY! What's weird is that muted notes show up in Quickscribe. What's with that? I would expect that deactivated notes would also be "turned off" when displaying notation.

What do you think?

Mike

I think it's an oversight that borders on bugginess. They should fix that, and they should give us some clear indication of which notes are muted.

[musicman691]

I love the fact that you can now mute MIDI notes. This deserves a big HOOORAY! What's weird is that muted notes show up in Quickscribe. What's with that? I would expect that deactivated notes would also be "turned off" when displaying notation.

What do you think?

Mike

I think it's an oversight that borders on bugginess. They should fix that, and they should give us some clear indication of which notes are muted.

I can tell the muted notes in the MIDI editor; I don't use QuickScribe. But even in the MIDI editor it's not all that easy to tell what notes are muted. Having a color choice for muted notes would be good in all screens. What would also be good is to be able to select a bunch of notes and have a right click menu that has the mute notes selection right there.

[wvandyck]

Having a color choice for muted notes would be good in all screens. What would also be good is to be able to select a bunch of notes and have a right click menu that has the mute notes selection right there.

And a "Select muted notes" menu option or key command.

I think it's an oversight that borders on bugginess. They should fix that, and they should give us some clear indication of which notes are muted.

I just noticed the Event List indicates muted notes as "display-only" which is a borrowed QuickScribe functionality. Copied and pasted code. No doubt an oversimplification.

Since muted notes are "display-only", selecting the QS menu item Display-only Notes>Select All, selects them and colorizes them blue.

Use of the aforementioned "Select Similar (by type)" with "Based settings on current selection" search when selecting a note in QS that looks like a normal note but is display only, will also select and colorize the muted notes.

All cool stuff.
But a dedicated menu item or key command would be most welcome.

[musicman691]

And a "Select muted notes" menu option or key command.

I just noticed the Event List indicates muted notes as "display-only" which is a borrowed QuickScribe functionality. Copied and pasted code. No doubt an oversimplification.

Since muted notes are "display-only", selecting the QS menu item Display-only Notes>Select All, selects them and colorizes them blue.

Use of the aforementioned "Select Similar (by type)" with "Based settings on current selection" search when selecting a note in QS that looks like a normal note but is display only, will also select and colorize the muted notes.

All cool stuff.
But a dedicated menu item or key command would be most welcome.

Your description gives me the feeling that MOTU just used code they already had in the program and added macros to accomplish the new features. Witness the new MIDI learn feature that uses custom consoles; who knows what else they did like this instead of writing specific code to do the deed.

[wvandyck]

Your description gives me the feeling that MOTU just used code they already had in the program and added macros to accomplish the new features. Witness the new MIDI learn feature that uses custom consoles; who knows what else they did like this instead of writing specific code to do the deed.

I don't understand how code works, but I can see how it would make sense for MOTU to repurpose what already exists.

At this point, I'm just happy to have Mute tool functionality for MIDI.

[Shooshie]

Your description gives me the feeling that MOTU just used code they already had in the program and added macros to accomplish the new features. Witness the new MIDI learn feature that uses custom consoles; who knows what else they did like this instead of writing specific code to do the deed.

I haven't installed DP9 yet, but am following it here. It's D/L'd on my desktop, but I don't have time to get to it yet. Bad timing. Anyway, what you say is my concern, too, and has been ever since NAMM when they announced they would be using Custom Consoles in this way. I hoped it meant they were revising Custom Consoles, but if instead they just did some internal macros to set up specific use formats, then the behavior could be very strange. Custom Consoles have never quite been ready for prime time. Always a buggy feel to it, and yet once you get them working, they generally stay working. I've got consoles from the early 1990s that still do exactly what they were set up to do. It's just hard to write new ones. One of the problems I've seen in the past year in Custom Consoles is a difficulty in getting some of them to stay assigned to the tracks you set them up for. Come back later, and there was a chance you'd have to go back in and teach it what tracks to act upon, and what to do, all over again. Not a certainty, but when it happened, it consistently happened to that console. Inconsistent bugs are the most difficult kind. You never know if it's something YOU did, or something just not quite wired up right in the programming.

In any case, I suspect MOTU programmers will be revisiting the code for Custom Consoles in the near future as bug reports and support cases come rolling in for strange behaviors. If they get them perfected, this could be a huge breakthrough for DP, because Custom Consoles always had the potential to be a breakaway technology unequalled anywhere else. But it never made it to that level, because the consoles were so awkward and "fiddly" to create.

I'm hoping for the scenario in which MOTU Programmers dive in, find the rat's nest of code, fix it, streamline it, and enhance its capabilities, updated for the 21st Century. That would be a great outcome! Until then, I'll be careful when using anything that relies on these consoles as the base code.

Shooshie

[stubbsonic]

It would be ideal to see some preference setting for how muted MIDI notes are handled.

In MIDI Editor:
() show as normal
() show as half-tone (or stripes or custom)
() hide

In QuickScribe Parts/Scores:
() show as normal
() show as half-tone (or stripes or custom)
() hide

Etc.

[bayswater]

In any case, I suspect MOTU programmers will be revisiting the code for Custom Consoles in the near future as bug reports and support cases come rolling in for strange behaviors. If they get them perfected, this could be a huge breakthrough for DP, because Custom Consoles always had the potential to be a breakaway technology unequalled anywhere else. But it never made it to that level, because the consoles were so awkward and "fiddly" to create.

I hope it is improved. I think the breakthrough would be ease of use, not the capability. Logic's Environment and Cubase's Logical Processor (I think that was the name) do the same, and in the case of Logic, a lot more, but both are just too difficult to use. Custom Consoles look to me like the result of recognition that MIDI data can and should be processable. The approach taken appears to be to a practical focus on things musicians are likely to use, rather than programming something because we can, but it does still feel unfinished.

[musicman691]

Your description gives me the feeling that MOTU just used code they already had in the program and added macros to accomplish the new features. Witness the new MIDI learn feature that uses custom consoles; who knows what else they did like this instead of writing specific code to do the deed.

I haven't installed DP9 yet, but am following it here. It's D/L'd on my desktop, but I don't have time to get to it yet. Bad timing. Anyway, what you say is my concern, too, and has been ever since NAMM when they announced they would be using Custom Consoles in this way. I hoped it meant they were revising Custom Consoles, but if instead they just did some internal macros to set up specific use formats, then the behavior could be very strange. Custom Consoles have never quite been ready for prime time. Always a buggy feel to it, and yet once you get them working, they generally stay working. I've got consoles from the early 1990s that still do exactly what they were set up to do. It's just hard to write new ones. One of the problems I've seen in the past year in Custom Consoles is a difficulty in getting some of them to stay assigned to the tracks you set them up for. Come back later, and there was a chance you'd have to go back in and teach it what tracks to act upon, and what to do, all over again. Not a certainty, but when it happened, it consistently happened to that console. Inconsistent bugs are the most difficult kind. You never know if it's something YOU did, or something just not quite wired up right in the programming.

In any case, I suspect MOTU programmers will be revisiting the code for Custom Consoles in the near future as bug reports and support cases come rolling in for strange behaviors. If they get them perfected, this could be a huge breakthrough for DP, because Custom Consoles always had the potential to be a breakaway technology unequalled anywhere else. But it never made it to that level, because the consoles were so awkward and "fiddly" to create.

I'm hoping for the scenario in which MOTU Programmers dive in, find the rat's nest of code, fix it, streamline it, and enhance its capabilities, updated for the 21st Century. That would be a great outcome! Until then, I'll be careful when using anything that relies on these consoles as the base code.

Shooshie

I've run into the exact problem you talking about getting them to stay assigned to the tracks you set them for. You're also not the first one to mention that custom consoles are not quite ready for real work. I thought that maybe it was me having problems understanding the concepts (which is possible) but just when I think I have it figured out something totally off the wall happens.

[wvandyck]

It would be ideal to see some preference setting for how muted MIDI notes are handled.

In MIDI Editor:
() show as normal
() show as half-tone (or stripes or custom)
() hide

In QuickScribe Parts/Scores:
() show as normal
() show as half-tone (or stripes or custom)
() hide

Etc.

All good options for preferences, or, the View Filter.
Either way.

[Shooshie]

I hope it is improved. I think the breakthrough would be ease of use, not the capability.

I was thinking a combination of both, but foremost should be the ease of setting one up. It needs to be more like MIDI Learn. I confess I have no idea how to go about it, but it's got to be ingenious! And if you could make one, then apply it easily to any track, with intuitive retro-fitting for that track, it would bring them into the realm of usability for all. By their very nature, you literally have to program them for every single thing they do. Apply it to a different track, and you're talking about different data, different sources and targets, so how to make it "know" what it's supposed to do would be way above my pay grade. I'm just sayin'.

One area that needs more capability is uniform sources and targets. You can select some things for conversion, but not others. It would be nice if they came up with a way to select Velocity, for example, and convert it to something else, or vice versa. The problem is that Velocities only happen exactly on the mark of the "note-on" command. That's one/480th a subdivision of a beat. So, the target also has to fall on that mark, or else it gets no signal to convert. SO, it has to "know" the velocity for the duration of the note or until the next attack, which currently it very much does NOT know. Other conversions would include tempo markers, which would have to function as Velocity should — it should know the tempo until the next marker; and there are other data forms which I can't think of, but which I've tried to use in Custom Consoles in the past, but was not successful.

I've created scenarios where the data was first converted by a MIDI data conversion plugin, then it went to another track via Custom Console, which went to my Kurzweil for some reason (it's been 10 years or more), then to a fader and QuicKeys and I don't know what all. The point is that to get what I wanted was a very complicated thing to do, and it only worked a few times.

Oh, and another thing that needed work was SysEx. It supposedly could be used dynamically in Custom Consoles, but I never once was able to get it to work. For years, I tried each new version of DP to see if I could make it work, but it never did. Could be user error, but I followed the manual exactly, many times. The hope was that I could send dynamic lighting cues, using on-screen faders and MIDI Show Control. I was able to send pre-programmed cues, so I know my formats were correct. But to get the Custom Console to send a variable bit via a fader — which it says it can do — just proved to be too much for me. Maybe someone else has succeeded at it.

I would love to see the whole thing reworked. It could be a very attractive feature of DP, which could be the hub of tremendous automation, streamlined user interface, and things we probably haven't even thought of. But until they make it work all the time, it probably is going to be a source of frustration more than anything.

I'm speaking out-of-turn; I haven't even installed DP9 yet. But this is my experience after 20+ years of custom consoles. Don't think that I'm saying Custom Consoles don't work; I've used hundreds of them over the years, and they've made my job a lot easier. Many uses were surprisingly creative; you would not have thought it was possible. But I've lost my patience for creating them, largely because of the problem of keeping new ones assigned as I left them.

Interestingly, one of the posts I remember on the subject of the new uses for CC in DP9 was that the next time they opened the file, they had to set it up again. Same problem as before, but now with macros.

Shoosh