JohnK

I think you nailed it! I checked my plugins and all the 64b ones were on , and the 32b ones were all off (at least the handful I checked). Thanks! Its not like WE consciously set it like this, it appears to be a bug (and I have logged it as a bug, I think the link is above) and I will transfer all the above info into that thread. I also have personally only just started using cakewalk again (long time user of Sonar, started with Cakewalk 1.0 for Windows, and have had a break for a few years). However, I must admit, I did notice my snare on one track was a little ahead, pushing the track along. I kinda liked it, may edit the actual timings... Also, if ALL your VSTis are 32b, then they are ALL delayed. I think this bug is a big issue with a lot of free VSTi (and hence this thread) as they are getting long in the tooth, and are commonly 32b and dev is shelved, so it is very relevant to free instruments. However, as I said I will be moving it into my bug post.

I am running Win7, and it is off by default for every VSTi, and even when I turn it on, it deselects itself on changing projects or shutting CW off (i.e. it is off 100% of the time for 100% of VSTi's). But this VSTi is the only one where I have noticed Timing issues. However, I normally run at 3-5ms latency, so even on this synth, I did not perceive it till something happened and my latency was bumped to 40ms without my input. Is it or could it be a Win7 thing only? as I said in the bug report, the other options are saved and restored.

For anyone using this synth, one thing to check: I have to use the "Enable delay compensation" in "VST Plug-In Properties". UI did not notice it at first because my buffer means a latency of only 3-5ms, which I dont really hear. However, another VST crashed and pushed it out to 40ms+. All of a sudden, my S-YXG50 tracks were out of time. Until I selected the "Enable delay compensation". I am guessing its also there at 3ms normally, but just not easily perceivable. The really ugly part of the above, is that the above setting appears to be lost when you change projects or shutdown Cakewalk, and is not even saved if you open the same project up again. I have logged a bug here: https://discuss.cakewalk.com/index.php?/topic/18641-bug-some-vsti-plug-in-properties-need-to-be-re-set-on-new-and-opening-projects/ The other thing I have found, although you can set multiple unique channels to be Drum parts, and select different Drum patches on each, it actually sets ALL the drum channels to be the same Patch/Reverb/Chorus. ================= EDIT: Read below, it appears to be a bug with all 32b VSTis default config.

I have a VSTi that needs the "Enable delay compensation" set. When I select / set this property for a VSTi, it is lost on closing the project and/or opening a new project, including re-opening this same project. i.e. It appears to not be saved and reloaded. I would expect this property to be a system wide setting for the VSTi. I also use JBridge for another VSTi, and I note that this setting IS saved between sessions/projects/startups and on new instances. i.e. it acts as a system wide setting as expected. I have not checked/thought about any other settings on this page, but as a concept of where these settings are, I would of expected all these settings to be system wide and automatically set on every startup and use of the VSTi.

Firstly, how are you getting Hypersonic to work at all? Which version are you running? are you using JBridge?

How would it be different to the chorus and reverb dials on a MIDI track? i.e. CC91 & CC93 If the specific VSTi does not support Reverb or Chorus, you can add the VST FX Effect to the audio track (or better through an AUX bus), Are you asking for an automated control/dial to do these steps for you?

For full disclosure, I am running Windows 7 64b. When I select to not show the Volume slider in the MIDI track inspector, the dials for chorus and reverb permanently disappear when scrolled out of view, and do not come back when scrolled back into view. See the image for how to duplicate it (read left to right). Also, I think the inspector has to be docked. From memory, it behaves differently when In a floating window.

if you are talking about the gain knob, then that is to duplicate Audio gain. i explained that in the text. By keeping the interface the same, people may feel more comfortable with the familiar, and less confused. Having "gain" on a MIDI track is the real start of the issue. i.e. consistency in the interface design. And -127 to +127 doesn't really mean as much, when in reality I am crossing 3 parameters, each of which is adjustable by -127 to +127, so if you wish to talk MIDI ranges, we are heading into MSB & LSB territory, and a range somewhere between -384 and +384. The actual values of the scale are completely irrelevant. Its simply a label, and I used the values of that label as placeholders to show what I mean. If its -18 to +18 or -127 to +127 is irrelevant to the central concept. i.e. mapping & scaling multiple MIDI controls, off of a single knob. I am fine with whatever scale. Its a detail that could be finalised at anytime. Simply replace -127 where you see -18 (and also the fractional breakpoints, and the +ve's versions) and all the math's stays the same. The real contentious issue would be the breakpoints & over lapping the breakpoints etc etc. For example, I know I personally only use expression in a very limited way, so, overlapping volume and Velocity over the Expression part would have more of a predictable effect, in most of my own projects. I was going to do another drawing of the breakpoints graph (with overlapping), but then I realised that would simply add more confusion and distract from the simple idea of combining the three values, into one end result, controlled by one value (i.e. the gain knob). PS: that logarithmic scale of audio gain, provided me the markers I presented above. i.e. -18, -12, -6, 0 etc etc in what I think are an angular linear delta. The interface is the important part of duplicating Audio gain. Currently its using velocity alone, which could even be negative.

Here are the details I have been promising. The concept is to mimic gain on audio as closely as possible using MIDI. That gives us 3 main adjustments. Volume (CC07), Expression (CC11 ignoring fine) and Velocity (Velocity of note on). By turning the gain, a formula can be used to adjust (i.e. scale up or down) each of these, so as to implement a virtual MIDI gain by adjusting the 3 aforementioned parameters. To mimic audio gain, I have set the markers/limits to be the exact same as audio gain. i.e. -18 to +18. The following is the MIDI gain at the three different positions. Exactly like Audio gain. The amount dialed in would scale each parameter in a % type calculation proportional to the amount the dial is turned. There would be break-points in the dial, where different types of adjustments would kick in. NOTE: The break points I chose are pretty arbitrary and there could be thousands of different options that should be investigated during final implementation. The following is simply a “straw man” to be able to talk to something. The amount they kick in is proportion to how much the dial is turned and the value is based on the actual recorded MIDI value, multiplied by the dial amount (i.e. a scaling factor). The adjustment would be done on the fly, and not show up on the corresponding sliders. e.g. if the dial causes the volume to increase, the volume slider remains wherever you set it, but Cakewalk will send the calculated value to the synth. For -18 to 0, I think we could use the no-brainer of simply adjusting the volume i.e. CC07. The other parameters (i.e. Expression and velocity do not need to be altered as volume overrides them. Then, I think that from 0 to say 6, the volume would be increased to a max at a gain of 6. From 6 to 12, the expression is increased. And finally, from 12 to 18, the velocity is increased. All these increases are a % (multiplication) of the original value up to the max value i.e.127). This next picture/graph shows one example of the dial being turned up (the X axis), and the effects on the values of the three parameters (Y Axis). n this example all the input values are at 64 (as can be seen by the values at Gain=0), and the MIDI Gain dial is turned up from left (-18) to right (+18) An interesting thing I realised, when the dial is at the extreme max, the velocity goes to 127, which on many patches changes the timbre, possibly in a similar sounding way to clipping/distortion on audio gain behaves when its too high. Now the calcs The BIG thing to remember here is that ALL the following complexity is hidden from the user. In my formulae below, a “v” at the end denotes the current recorded value. And an “n” denotes the new calculated value that is sent to the device. Note, the break points I chose are kind of arbitrary and these would be adjusted to make the knob act in a more natural sounding manner. For example, the break-points would probably sound smoother if there was overlap. Also note that the values used are at the exact point in time. So if an envelope is on expression, then the envelope would be scaled as per the formulae. CC07v = VOLUMEv = Current Volume slider value (min of 0 to max of 127) Could be set by an envelope CC11v = EXPRESSIONv = Current value of expression (usually set by an envelope), 127 used if no expression is set. VELOCITYv =Velocity of the current MIDI note on KNOBv = Gain knob value [-18 to 0 to +18.0. Which matches the track audio gain knob] The following image simply shows the Gain ranges used below in the calcs. Knob Range of -18.0 to 0.0 CC07n=((18 + KNOBv) / 18) x VOLUMEv [for 0.0 it goes to 1.0 * VOLUMEv = VOLUMEv = CC07v)s CC11 = CC11 VELOCITYn = VELOCITYv Knob Range of 0.0 to +6.0 CC07n = (KNOBv / 6) x (127-VOLUMEv) CC11n = CC11v VELOCITYn = VELOCITYv Knob Range of +6.0 to +12.0 CC07n =127 CC11n = EXPRESSIONv + (KNOBv -6) / 6 x (127 - EXPRESSIONv) VELOCITYn = VELOCITYv Knob Range of +12.0 to +18.0 CC07 = 127 CC11 = 127 VELOCITYn = VELOCITYv + (KNOBv -12) / 6 x (127 - VELOCITYv) The Results: For clarity, from the above formulae, I have created a spreadsheet showing some randomly selected values. And made it pretty with colours. I didn’t bother showing -18 to 0 as it is simply Volume that changes from 0 to the current value set by the volume slider, and all others stay unchanged. The 3 columns on the left are the MIDI values , while the top row 0 to +18 is the gain knob value. Hopefully all the above is clear, and I didn't make too many typos.

oops... forgot to answer your question regarding what I use to play soundfonts through, I use BassMIDIVsti. See my other post: I am not sure if the dev has updated the public release version to fix an issue with it working specifically with Cakewalk (a sample rate dif), but I have a version the dev gave me to test, and it works 100%.

We can not expect Cakewalk to work with VSTi that break the rules or are broken. i.e. do not listen/respond to CC7. As for CSMultiCompander, I responded to that in the very post just before before yours! And when I get around to expanding on my concept, it will be much clearer why this control will not do the same.

let me answer the easy ones first,. 1. Yes, but multiple parameters. I ill explain what I mean by that in a later post. It is complex, and the devil is in the detail; NB; the single dial interface would be hiding the complexity from the composer, as all good software does. 2. As I will explain the multiple parameters later, for simplicity, and I am not 100% firm on it at this stage (As its still not set in stone in my mind and the devil is in the detail) I would propose that the range of values would more likely be conceptually -infinity to +infinity. -infinity (although kinda useless) would conceptually be telling CW to do everything possible to make the resultant volume 0; basically act like muting the track and hence redundant. The actual -infinity setting would be practically useless in my eyes, BUT the dial position JUST before it may be of use; ie as quiet as possible without being muted. However, the +ve infinity could useful, by asking CW to do everything possible (within the track), to make what is playing, as loud as possible. When I explain later what/how I am thinking this would be achieved, it will also become clearer. That control has the issue that it is not a prominent dial (ie Gain) in the midi inspection track. I haven't looked too far into it (there are warnings its still in dev and should not be considered bug free). On first glance, it looks like it may be able to effectively achieve the same results I am thinking of, but would require a LOT more complex configuration over using a single dial.

And that's exactly what i was thinking. however, as i said above, I read the MIDI specs and the soundfont specs (which was the patch i was using), and they both explicitly document that CC11 ONLY changes the volume. And as the SoundFont spec details so, the engine would/should not have a mapping of CC11 to pitch or the LFO depth. It has been a while since I have made my own soundfonts with something like Vienna to check if that is the case when creating a patch. I tested a few existing string/orchestral patches I had as SoundFonts, and they did not respond to CC11 with anything but volume.

Ok, so I have two things I need to say. 1. SORRY! and for what I am sorry, about, see point 2. 2. I was WRONG regarding expression not being a kind of volume control. I did an actual check of the MIDI specs and Soundfont specs, and it IS an adjustment of ONLY volume. The volume (CC7) sets the maximum value for volume, and expression (CC11) is for the adjustment from 0 and up to the max volume set by CC7. I thought otherwise because an old CWP I opened that used CC11 to fade out near the end on a strings track, had some extreme vibrato that wasn't there originally. I thought that maybe the old VSTi I used to load/play the soundfont did not respect vibrato on expression. In hind sight, maybe it was actually a delayed vibrato on the patch. After reading the specs, I went back and tested the VSTi with other patches, and there was no vibrato added with CC11. So, sorry about all that, my bad. I will go back and mark those statements as incorrect in my old posts (I will simply leave them in, but strike them out to keep the logic in the flow). The other thing I learnt reading the specs, is that CC11 is actually the course control, and there is another one for fine control (CC43) to enable 128 different levels between each of the 128 levels of CC11. No-one uses or even supports it, as it really becomes theoretical to be able to hear the volume adjustments down to that detail. Even though this re-enables my ability to control track volume (now that I know CC11 operates how I though it did a week ago), I still think for all the other reason above, that mapping track Gain on a MIDI channel to velocity, is far from optimal. Regarding the above questions by User 905133, I will answer these a little later, possibly with diagrams!, I have a few things I need to sort in the physical world first.

i'm all about the MIDI

NOW we are getting somewhere! thanks!👍 I just tried it on one project & track, and it sounds to do exactly what I need. However, when I read the documentation, it sounds like mathematically, it would not. For example, in offset mode, say I have a volume envelope that goes down linearly from 127 to 0 over 1 bar (in 4/4 for this example), and I set the track volume to 64 (ie a mathematically -64 offset). To me, at the middle of the bar (ie 1:03:000), the envelope would be 64, and the offset would be -64, so it would send 0 for volume to the track . But when I solo the track, I *think* i can still hear it past that point. I need to do more tests/investigation. I'm obviously doing something wrong or miss-understanding it big time, or hearing things that are not there.

The above may be common for you. My set up is that I commonly use 2 or more multi-timbral synths, each capable of 16 parts each. And Cakewalk itself comes with a 16 part multi-timbral synth; i.e. TTS, and a big feature of MIDI is 16 parts, so I am not the only one that uses multi-timbral synths. Under this use case, I will take you through why each of your "10" (only 7 by my count) volume controls do not work as a track volume. But first, lets address the same issue again. Read my OP, as far as I can read, nowhere do I mention or hint at anything about "selecting 10" envelopes, or ten tracks. Please, this request has NOTHING TO DO WITH MULTIPLE SELECTS. Or please quote where in the OP I am not clear. and have even hinted at multiple track selection OR envelope selection? And back to your 10 ideas (7 by my count) for TRACK volume: 1. A sample Violin track (Just assume I have 4 violin voices I am working with) Midi volume I have a control for track volume in the interface in Cakewalk, BUT this control gets cancelled out / over-ridden, if I use an envelope (and to be clear, that is a single envelope) for MIDI volume. So now, I cannot change the volume with the track volume slider. Further, if I am doing a mix down, to change the volume mix of the part in question, I have to edit and change every single inflection/elbow point in the envelope. And this edit is a destructive edit. Now if I am playing the little up / little down game, this will become very arduous (remember, every elbow point), and destructive. 2. Midi Velocity (I know not exactly volume on better VSTi's) As you agree, and as has been covered above, VELOCITY IS NOT A VOLUME CONTROL. i have patches that are ALL about their velocity response. Using an offset destroys the patch. 3. Synth Audio Volume I am using a multi-timbral synth (up to 16 parts) or multiple multi-timbral synths. So changing the overall synth audio out volume on this single synth, affects every part played by that synth (up to 16), not just the single track I am trying to change. So if I have two multi-timbral synths, I not only have to go back to each individual MIDI track and change each individual track volume of that synth in question (since the overall output has been altered) but also I am messing with the mix between each of the two (or more synths), where the other(s) one could have 16 tracks in itself. Adjusting the total synth volume destroys the mix between all tracks. In simple terms, its not a "track" volume when using a multi-timbral synth. And if I have volume envelopes on any of the affected synths, boy am I in for some pain. In simple terms, its not a "TRACK" volume. Having a multiplier as the gain averts all the above completely, as the gain/multiplier only affects that one synth track It is encapsulated in the specific MIDI track. 4. Synth Audio Gain Exactly the same issue and reason, it is not a "track" volume, see point 3. 5. Group 1 Violin Bus Volume and Gain->String Bus Exactly the same issue and reason, it is not a "track" volume, see point 3. 6. Group 2 String Bus Volume and Gain-> Music Bus Exactly the same issue and reason, it is not a "track" volume, see point 3. 7. Music bus to Volume and Gain->Master Bus Exactly the same issue and reason, it is not a "track" volume, see point 3. You also appear to have double counted some headings, as individual items/methods, as I only come to 7 from your post. Have I missed any? I only count that you proposed 7, all of which do not work as a TRACK volume, for the above given reasons. By Changing the gain to a volume multiplier: i. Only affects the one single track it is used on. Does not require you to go back and adjust every other track, after every single small adjustment ii. If you have a volume envelope(s), you do not need to edit it, as the multiplier does that all for you. NB: A volume envelope adjust is destructive. You go too low and you will lose resolution. Having gain as a multiplier, means you can draw it with full 127 step resolution and always keep it that way. iii. Its not an offset, but a multiplier. If you offset the velocity down 90%, some notes may end up with a velocity of 0 and thus will not be played by many instruments. An offset, mathematically speaking (and by what you hear), is also not relative in volume to the rest of the other tracks. iv. Removes the confusion of the duplication of having two differently named controls, for the exact same result i.e. velocity offset. v. Existing users that have used the velocity offset (including me) keep their values in the duplicated velocity offset control. i.e.nothing is lost, its only a gain (not meant to be a pun on words...). What in the above, and please use my reference numbers to clarify which point you are asking about, is invalid?

This would be a relatively low priority, however, I find myself using the bank select quite often.The issue I have with it, for synths that do not report their patch/bank back to Cakewalk, is that I have to pull out a calculator every-time to multiply out the MSB by 128 and add the LSB, to get to the desired bank, from which to select the patch. A simple idea (not necessarily simple to execute) would be if when in the bank select in edit by text (as shown in the first attached image), if a pop-up appeared that allowed entering the bank number by MSB and LSB would make it soooo much simpler and less painful. For example, the number 272 below is MSB=2 LSB=16. I did a very quick mock-up to give an idea of how it may look more useful (attached image 2). Labels would probably help, but the mock-up is done. Of course the feature request below would alleviate a lot of the need, but not completely.

But if you read the actual OP. It is NOT two volume controls. And if its is confusing, it is also confusing in the audio tracks, where the gain acts as a secondary volume trim. But are you saying two volume controls, which actually have different purposes, is more confusing than having two velocity offset controls that do the EXACT same thing? Even if it were more confusing, converting the Gain control on MIDI tracks adds functionality that there is currently no other simple way of achieving. While two velocity trim controls obviously waste the extra control. Extra functionality, can be more confusing, but other users do not like unnecessary redundancy, especially when it is limiting.Currently, I have no way to lower or raise the volume on a single track of a multitimbral synth , which has a volume envelope, without modifying the envelope to suit the current other specifics. The multiplier as gain, would be a significantly more generic system which would mimic the same control on an audio track, much more closely. Audio does not have velocity, and if you don't wish to use the gain multiplier, use the velocity offset, which is exactly what you want. But, without the gain multiplier, you have two velocity offset controls, and the rest of us have nothing.

I updated the last Cakewalk when offered. However, since doing the upgrade, any projects that use Absynth fail to load Absynth, with a "not registered" warning. So, I went to re-register it, but it says it IS already registered. Also, I can load and run it without issues inside its own host, and also using SAVIHost. Absynth is a 32b version VST, and i am running win7. However, as I said, it worked perfectly in the previous version, and continues to work perfectly outside of Cakewalk.

Obviously. I disagree. As I said, I didn't think it was really a bug in operation, but I think it is a weakness in the design, that could be improved to provide an extra layer of functionality. Having 2 volume controls is no more "wrong" than two velocity controls. EXCEPT, the second volume control I am suggesting, acts differently, while the second velocity, does the exact same thing. i.e. no benefit, while my version of the gain control has a big benefit. So, less, ummm... wrong. As for the expression control. That's what actually got me looking into what the gain control did on a MIDI track in the first place. I had an old project that used an envelope on the expression control, as a pseudo second stage volume control. When I upgraded my sound-font player, the track actually started to present an unwanted vibrato. Which, I realised (actually assumed) is how the expression control should be acting per the sound-font specs. My previous softsynth had a bug, that I was taking advantage of. In short, the expression control is NOT for use as a volume trim control. So, that leads me back to a fix to the duplicated Gain control, to better mimic a gain control of an audio track, which it obviously is there for.

You appear to have missed my point completely. I spoke nowhere about selecting multiple tracks? As for a velocity sensitive organ, that was simply and purely an example of a patch that MAY be not velocity sensitive at all. All the organ patches that I remember using are actually velocity sensitive, but in the real physical world, an organ is not, and hence I used it as an EXAMPLE, not a complaint that they are not velocity sensitive. I simply couldn't think of a better example of an instrument that is not velocity sensitive, and hence would NOT respond to the gain control as it stands. A "good organ patch" is 100% irrelevant. I have over 1K organ patches on top of those in the 70+ GM SoundFonts, and I have probably only used many less than 5 in all my tracks. As for the extra's, that has nothing to do with if the gain control could be improved or should be changed. I am not looking for ANOTHER plugin to plug holes in CW. Especially when changing the Gain control as I suggest, would up the functionality built into Cakewalk.

Not sure what video you watched, but I think the request itself is pretty self-evident, and has had a big reaction from other users. I also finished adding the following post on MIDI track gain. Which I think would be relatively easy to change.

MIDI track gain It isn't really a "bug" as it does what it says its suppose to do, but, I think it should be doing something else. It is trying to mimic track gain, that is present on audio channels, but I think it fails in its design in the following ways. To simplify my post I'll let you in on what i think it should do. I propose that it should instead act as a multiplying factor of the MIDI controller for volume. So, at 0 it would leave the volume as it is, if turned to the left (say -0.9) it would only be 10% of the volume (MIDI Ctrl 7). If turned up way to the right (say +2.0) it would be 200% of the tracks volume slider value. Some points on why I call it a failure: 1. Track gain on an audio channel makes no difference to the timber. On midi, the velocity of a patch will significantly change the timber of the patch. For example on many patches, the filter will open more if I increase the velocity. 2. On a piano simulation, lowering the velocity below a threshold would mean notes would not be played at all. ie skipped. But on an Audio track gain, they simply get played but very softly. 3. On an organ patch, which is not velocity sensitive, it would have no effect at all. 4. It is a duplication of +velocity, and thereby wasted and confusing to the user. 5. The tonality of a synth that has very distinct sample layers or an analogue simulation with a lot of resonance and a big mapping of velocity to cut-off, the sound would be adversely affected. ie not as the user may play in with variable velocities. The benefits of using a multiplying effect to volume: 1. All the tonality changes due to performance velocity differences are kept. Therefore its more life-like, and less mono-toned. As would be the case if the velocities are simply bumped up all to the max. 2. The Volume envelopes remain valid, and act as a % of max volume. This benefit is actually what started me down this rabbit hole. If I have say 10 volume envelopes, I have to edit every one of these individually to actually change the mix of the track in the final outcome. If the gain worked as a multiplying factor, then all the envelopes would simply by multiplied up or down by the gain multiplying factor. I could leave the volume envelopes alone, and change the level of the track in the mix, via the gain. 3. Remove the duplication and wasted control. As its already there as something else Thats all I can think of right now...

I dont know how easy, but I started this feature request thread. I am also just typing up a bug/feature request regarding the "Gain" knob on MIDI tracks.