Hi, I downloaded today latest version (1.2.6) after try previous one yesterday and discovered the new one has a bug with the "master volume" when working with VSTi. My configuration is Windows XP SP3 32-Bit, Cubase SX 3. I first loaded East West Symphonic Orchestra Gold and played some notes, all OK at this point, but when I created a chord It started to sound very loud then I discovered the "Master volume knob" was on it maximun (12db). Then tried with another VSTi (Realstrat) and It happened again, "Master volume" of the VSTi interface at maximun. Tried to restart cubase, same thing. Finally tried to install again v1.2.5 and there was no bug.
Posted 2009-12-16 1:25 AM (#14934 - in reply to #14933) Subject: Re: Midi bug in v.1.2.6 ??
CS is right - the volume entry associated with a Note On is used to set the MIDI velocity, but all other volume changes are transmitted as MIDI channel volume messages. It's a built-in limitation of MIDI that you can only have one volume for all the notes on a channel, unless you set different velocities or use aftertouch. If you want to have a volume other than max., you can adjust the Global Volume setting for that instrument (F4, Volume).
Alternatively, if you want to disable all CC7 volume messages from reViSiT, you could filter them out using one of Cubase's MIDI effects.
It's odd that the behaviour changes between 1.2.5 and 1.2.6, because the code certainly hasn't - it's possible your VSTi's react differently under different circumstances. They can choose not to react to specific messages when they don't feel like it.
Posted 2009-12-16 11:44 PM (#14944 - in reply to #14931) Subject: Re: Midi bug in v.1.2.6 ??
Chris, I understand, but, why the volume changes without sending any CC7 message ? I mean, If I enter let's say a plain "C-4" for an instrument associated to a VSTi, why suddenly when it happens if I add on the next channel any other plain note (same velocity), the volume on the vsti gets changed to maximun ??
It should mantain the default CC7 value as said for ALL notes, unless I manually change that value, so why the CC7 volume changes itself without manually change the CC7 value ?
Playing again now It seems this happen some sort or random, so I will try to recolect more information on it when it happens again. If I get to reproduce totally this behaviour I will write down all the information so we can get why this happens. What I don't understand well is why it seems to be random when doing the same (or almost) steps.
With audio, each note can maintain it's own volume; but, for MIDI, a single Channel Volume is shared by all notes on that MIDI Channel. To ensure the new note is at the correct (default) volume, a CC#7 message is sent. So in this example, the Channel Volume goes 64 (127), 32 (64), 64 (127), as each row is processed. This is done so that, in the majority of situations, MIDI performances behave the same as audio ones. For example, in the above excerpt, you'd expect the G-5 to be the default volume (e.g. 64), just like the C-5 - the 32 volume entry affects only the C-5, just like audio instruments. However, as you have noticed, this behaviour is problematic with polyphony:
Theoretically, I could have reViSiT detect when a MIDI channel already has activity on it, and if it does, have any new notes assume the volume of the previous ones. However, with so many conditional cases, it becomes increasingly hard for the user to work out what's going on - the behaviour at any point relies on what has gone on elsewhere - in another channel or even pattern.
For you, one workaround would be to manually insert a CC#7 MIDI Effect (0xx to 9xx) to maintain the dipped volume on the G-5 note:
I had thought another option would be for you to dip the volume by setting the channel volume on the second track. However, I've noticed reViSiT currently doesn't use the channel volume when calculating MIDI volumes - but, if no one has any objections, I'll add that in for the next release. With such a modification, the following would thus also work:
Posted 2009-12-17 3:37 AM (#14946 - in reply to #14931) Subject: Re: Midi bug in v.1.2.6 ??
Ok, I think I am starting to really understand how is revisit working with the CC7 (thanx a lot about last explanation). And I think I know what could happened about what I called "bug". I will try to explain, It seems somehow the VSTi (or some VSTi) when recieve midi data from revisit don't refresh the value the first time. For example, revisit has XX as default volume value, if I open the VSTi GUI and use the mouse to manually change the volume when I go to revisit again and press or write some note, the VSTi ignores completely the CC7 message, but when I write or press the next note this time the CC7 message is recieved ok by the VSTi (and of course refreshed on the GUI). What got me crazy yesterday was that sometimes and with the same VSTis It also happens with the very first load of the VSTi. First note with default VSTi CC7 volume and next notes with revisit one. What I don't know if this is a problem related only to the VSTis or if has something with the own revisit. But in any case, I hope resolved the mistery. (Note: I had just now that strange behaviour of yesterday after load a new VSTi with the volume problem and It seems sometimes is not only the first note ignoring the CC7 message, it can be more of then (about 4 this time) but eventually it recieved correctly the default volume setting).
And returning to how revisit manage CC7 messages I was using wrong the 9xx command, trying to use hex instead dec, and not using at all the "default volume" setting on the instruments window. Then following your explanation and using dec values and changing default volume I got complete control about the volume. All great at this point, but just a moment ago I "deleted" the VSTi and loaded a new one (the one of the note above about not updating the CC7 volume with the 4 first notes) and noticed something weird (that I thought it was my fault becausse of the hex values). Now that VSTi doesn't recognize at all any CC7 in the effect column, it works correctly when using from the volume column but on the effect column don't. I have assigned CC7 on command 9xx I checked is correctly in the settings.
Now, suddenly after changing again to the revisit window, and changed to next pattern, entering several notes with the 9xx command, it started to work, but not as it should, the very first note sounds with the default volume setting from instrument options, next ones get correctly the 9xx value. Also noticed now if I use alone (empty row) the 9xx command it works with the current sounding note but as above when using the 9xx command on the same row of a new note it doesn't work, only work for the next rows (with notes or not).
About the last questions of your reply yeah, I personally think too it would be a mess if the new notes assume the value from previous ones. The actual behaviour is perfect as It is now. And about the last suggestion I think too It is a very good idea to use the channel volume command to control midi channel volume as is completely logical.
Well, lasting I hope the information about the weird "bug" with the volume effect column to be important. So after all It seems to be really some kind of bug.
Posted 2009-12-17 4:19 PM (#14948 - in reply to #14946) Subject: Re: Midi bug in v.1.2.6 ??
Okay, I think I've worked out where your problem is. reViSiT's behaviour is as I explained, but a MIDI volume message will only be sent out when reViSiT thinks it is needed - MIDI communication is often slow, so it's best to keep the messages as few as possible.
Thus, it keeps track of the current MIDI volume for an instrument, and only sends MIDI volume messages when the requested value is different from the existing value. However, when a device's MIDI volume is changed without reViSiT knowing (e.g. tweaking the VSTi directly), reViSiT may not thus send a subsequent CC#7 message. For example:
Here, the C-5 starts with volume 64. Since reViSiT thinks nothing has changed by the G-5, which also requires volume 64, no CC#7 message is sent. Thus your VSTi tweaking means the volume you set directly will survive until the next change in reViSiT's own volume (e.g. 64->48).
Now, I could make it so that all new notes trigger CC#7 messages, but this would add a significant amount of extra MIDI traffic that might interfere with more complicated arrangements. Instead, I suggest you try sending a MIDI reset (F8 x 2) following any fiddling with the VSTi's directly. This not only resets reViSiT's record of volume changes, but also sends an All Controllers Off CC message, that should reset your VSTi to it's default volume, etc.
Posted 2009-12-17 6:39 PM (#14949 - in reply to #14931) Subject: RE: Midi bug in v.1.2.6 ??
Thanx for the explanation Chris. I think I understand correctly now the midi behaviour but if I send a manually CC7 message (a 932 effect) this message should always be sent isn't it ? Let's try to make an example:
This time what happens is the first note on the pattern sounds with default volume, ignoring completely the 932 changing volume effect, but the rest of the notes following handle correctly the 932 effect command so the notes sound with the correct volume sent.
I hope you understand now what I tried to say, what can be happening ??
Posted 2009-12-17 9:37 PM (#14950 - in reply to #14949) Subject: RE: Midi bug in v.1.2.6 ??
Any explicit MIDI effects (0xx to 9xx) are not subject to any "funny business" (e.g. remembering values or volumes, etc.), and should send the appropriate MIDI CC# every time. I've tested it with the MidiMonitor VSTi plugin to see what is actually being sent/received, and it looks fine:
(note: the last note off was me pressing Stop)
So, it sounds like your problems are down to the host or the VSTi. You should be able to find out which, if you grab the MidiMonitor plugin and try it yourself. If the Controller messages are missing, it's the host, otherwise its something to do with the VSTi.
'Hope this helps - let me know how you get on, Chris