Jam Origin

>> MIDI Guitar & MIDI Bass user forum

Stereo balance is thrown askew when changing buffer and bitrate for Interface


#1

Hi. Fresh forum member.
As I have searched this forum, I can’t find anything on it. I have a newsly fresh installed Mac OS, 10.11.6 with an M-audio Firewire soundcard. It has worked before, flawlessly. However, I discovered today that without ANY instrument (VSTi) loaded, or effect, of additional AMP, whenever changing the buffer from 128 to 256 or the other way around, with both 44,1 khz bitrate, and 48 khz bitrate, it throws the balance askew, and the right speaker, headphone, or channel shows suddenly a larger output, like the balance knob of a mixer is thrown askew.

Anyone else noticed this?

It can’t be remedied until one restarts MIDI Guitar 2 but then the settings are lost, and you have to go in again, and change them. The program doesn’t freeze or hang, you can start to load it with software synths and amps, but the balance is still askew. It hasn’t got anything to do with AU or VST or which plugins are used. EDIT: Oh I forgot, it’s no matter whether it’s standalone or inside any DAW.


#2

We never heard of this problem. please try whether loading on stereo or mono audiotrack in DAW makes a difference. i have no idea what causes the problem sofar.


#3

Ok I tried it now, to get rid of all other usual suspects I used ONLY standalone mode. As I am fortunate enough to own both a MacBook Pro (OSX 10.11) and a few Windows PC machines (all from XP even, Win7 and 10), I’ve tried it in all instances.

The “quirk” doesn’t occur at all on Windows machines. VST used.

Soundcard changed out even. It’s M-audio firewire 2626 on both, and I’ve tried some Echo Audiofire too. To change the soundcards a bit. So:

  1. Only on Mac OS, and let’s keep it standalone only.
  2. Whatever patch chosen, whatever plugin/amp used (AU,VST,VST3) if I hear that I am taxing the CPU (or watching the warnings) I want to lower the buffer/bitrate a bit and cope with the latency. If I change it, the output becomes slighty louder in right channel. Restarting MIDI Guitar remedies this but since I have not saved this setting with the patch, it goes back to the former buffer/bitrate say 44.1 Khz / 256. And then the stereo pan is right and dead on. As fast as I try to change it, well, not even try it, it actually is possible to change it, no problem, the output becomes all of a sudden, for no reason slightly askew to the right channel. If I save this patch with these settings, and then restarting the MIDI guitar 2, then it’s still askew, i e the right channel is louder than the rest.

I’ve checked and checked and even used the built in instruments, and tube amps that comes with MIDI Guitar 2 to not stir it up with 3rd party plugins. Checked my soundcard settings twice, and once again. Back and forth to no end. Now, if I go into the interface and try to change the bitrate/buffer to what it was before it doesn’t go back to perfect balance again, it stays with the slightly askew balance. Even if I chose unwieldy long bugger 512 and up, just for the sake of it. No intermediate software or plugins are running, and no “bridging” between 32 bit and 64 bit occurs. Standalone.

I checked the meters on the soundcard interface driver, and the right channel shows louder by quite a fair amount. I didn’t detect this until today… and yes, I even reinstalled it.

But is there no one else that have ever experienced this, it must be something at my place then…I can’t be alone, and it is a sort of subtle thing, that may be unnoticed by most people, either they don’t care about it, or haven’t done it. They stay with whatever bitrate/buffer they open up with and leave it at that.


#4

I reported a similar bug where changing sample rates resulted in large volume increases: Midi Guitar 2 Bug Standalone Gain Setting - Windows I am also using a firewire interface.


#5

Ipspecial yes that seems to be a valid one too. Definitely related. In my opinion. And it was a recent one, that bug of yours. I use standalone quite a lot, or really Midi Guitar 2 as a host of itself with many instances of plugins, both synths and guitar modelling amps. By and large it is easy to get lost with all gain, input and output volume settings there is on the panel. Input/Gain DB is on the interface panel, tracking has “noise gate” although not that related but can affect input too, Gain for midi velocity, gain for instrument, gain for amp/plugins and then at the end master gain. Easy to get lost… and then you have the volume/gain changes when altering buffer/bit rate…sorry, couldn’t resist…:slight_smile:


#6

If there is a pattern here, it is macos & firewire.
There is no special code inside MG for firewire audio: it all is apple’s coreaudio system.
There are overall settings in coreaudio most people don’t even know exist: they are governed in “Audio MIDI Setup”. the individual channel volumes can be changed there.
If the quirk resides on that side, setting the bitrate/buffersize would also introduce imbalance setting the bitrate inside a DAW, without MG loaded as plugin.
It is also worth testing whether setting the system’s audio output to another device makes a difference.

For completeness sake: Setting the bitrate and buffersize is not ment to be swapped all the time: it should be left at a convenient setting for all purposes.


#7

Thanks for clarification Paul. I tried it for - fun really - to use built in microphone and built in speakers, of the Mac, just for testing, but it didn’t show up there.

Yes, I know that one shouldn’t really swap the bitrate/buffersize all of the time. But in this standalone case, I didn’t mind particularly the added latency, because in this case I loaded a lot of ambient slow attack sounds, that are used to swell and fade in anyway, and doesn’t really gives a hoot about 15 ms added latency anyway. It was just that the synths and effects where of that “pad” soundtrack kind of thing, and I wanted to try how much it could take, for my purposes. After I adjusted the balance, I could play slow ambient parts with MIDI Guitar 2 and both Instrument plugin, FX, Master FX, and a Guitar Amp plug in, with subsequent after effects, as well as Master FX. Mostly delays and reverbs which chews on the CPU big time. The CPU meter was well below 20-15 percent then…

With another device, I think it would be an USB device which I don’t posses at the moment, but I can try to borrow one, or take my macBook over to a friend just for test purposes.


#8

Well, it takes time to find a convenient setting don’t you think? For all purposes. Then I think this one should be best set outside starting MG 2 in the first place, and leave it only to follow whatever is set on the audio interfaces control panel.

I’ve tried it now again, with only USB, and built in Test Piano synth enging included, and it behaves the same. I have set Core Audio Audio MIDI setup properly too. One should be able to test the “ceiling” or the roof before it starts to crackle and make noises due too to fast or low buffer/bitrate settings. If I want to play at faster settings than 256, say 64 or 32 I want to try this. The latency is big enough as it is anyway.

BTW with this I mean that the built in VU meters on the MG2 should be split into left/right meters too, otherwise you can’t find where the culprit is. Most plugins have stereo out, especially reverbs, delays and so on.

I’ve even detected that the sound changes to too loud when going to the interface panel and change the INPUT one (of your interface) to INPUT 2, I mean regardless of there
s anything plugged into input 2 on you interface card.


#9

you should put never things like reverb or delay in front of the mg input, so the stereo input VU is not needed.
Your test with using builtin audio with the mic proofs that it is the macos firewire audio system itself that causes the switching inconsistencies. We cant do much about that, the only thing worth checking is the “audio midi setup” app, maybe there is some kind of preset there going on. I cant check that because firewire is allready history for apple, and I dont have a working firewire machine anymore.
There are so many users using our app, and all the stuff that is in it can not be dismissed easily: a situation can be way too many knobs for many, and loved by a few. We tried to make a good tradeoff, but it is a difficult area. Which is proven by the fact that we are the only app offering the functionality in the first place… if it were easy we’d be just one of many…
But this is no reason for us to not strive for improvement.


#10

No of course don’t do anything at all, neither reverb, delay, compressors before at the input, even if it’s a mono signal. As clean and tight as possible.

But for the output side of things. It can very well be some reverbs, delays, or synths that has stereo, thrown askew. Now for your orientation. The screenshots are in the following:

  1. Those called “first” are whenever starting up MG2 and the initial Control Panel for M-audio interface.The interface screenshots are just for showing the meters before and after. NO ADJUSTMENT HAS BEEN MADE AT ALL on this control panel when comparing between the two instances. It’s just for display how high or low the meters hit at any given time.

  2. Those called “second” shows the altered samplerate/buffer inside MG2 and what the Control Panel for M-audio meters shows. Again, not any adjustment made at the M-audio control panel. The output just goes through the roof and shows red. The display shows just one red “overload” but if I could show you, there would be at least 7-8 more “red” bits on the right one, because the right one sounds considerably louder. There isn’t enough on the scale to show how loud and asked it really becomes:


#11


#12


#13


#14

Now the thing that is of notice, ist that none of the gain buttons or master level buttons inside MG2 goes to red or even orange.

For clarification: I used M-audio as a demonstrate exeample for screen shots, because that one is easier to read. Easy on the eye. I did produce the same results with and AudioFire Interface (still FireWire) and an USB device. They all reacted the same. On MacBook pro. Changing the samplerate inside any DAW on the Mac does not render these results.

I have not been able to reproduce the error on any Windows machine regardless of FireWire, USB or something else. As of yet, it should be said.

EDIT: As with the pic with high levels, they’re too high really, both channels turns well into the red, so one can’t detect that they are askew, one channel is lower (way) than the other. If it was possible I could turn them down so you could see the “unbalance”.


#15

Mats, I am on a Windows 10 machine, and that gain increase that you show is the same result I get. Somehow, when the buffer is switched it goes into high-gain mode, and I can’t get it out of it. Unlike your results, my audio also becomes corrupted in all other DAW applications that I use. Paul mentions not to switch the buffer settings and to just keep it where you set it initially. But, MG2 standalone will not keep the buffer setting that I switch my audio interface to, leaving me no choice but to switch it within the standalone application. Often times after launching MG2 standalone it doesn’t even launch with my audio interface loaded in the input/output section. I don’t know what is causing this issue. Over the weekend, I fixed the problem of being stuck in high gain–re-installed the driver and firmware on my audio interface, and did a complete clean install of my Windows 10 system. It is now working as it should. I can’t say that MG2 standalone definitively is the culprit of the audio corruption, but I can say that as long as I stay away from the standalone app, I don’t have the issues for the moment. Despite the problems I’ve encountered, I still use MG2 as a plugin without issue (if the audio doesn’t become corrupted after using the MG2 standalone program). This demonstrates how good the performance of the audio to midi conversion is–any other app would have been removed permanently from my system.


#16

Nice to hear Ipspecial. But in MG2 there is a possibility to save audio interface settings with the patch at least in standalone. Which makes sense. But whenever calling up those patches inside any DAW will still use the DAW’s settings. Also if you have a “high-end” rate and buffer as much as you can take the CPU, it may be better in standalone mode. In DAW mode, there’s the actual host application and other things that may hog the CPU so lowering the latency (i e lowering to long latency 10-15 ms) may be a necessity.

I do have discovered that if I save the patch INTO A NEW PATCH with saving audio interface settings it calls it up with the “high-end” fast settings and doesn’t produce the higher gain output anymore.

But, still…even that, it’s bit unwieldy and cumbersome. And no matter whih way you turn on it, a bug, albeit slight…


#17

In my experience, sometimes it recalls the audio settings saved in the patch and sometimes it doesn’t. Sometimes it opens with the last patch I used and sometimes it opens with the default Test Piano patch and Non-ASIO WDM drivers. I won’t being doing anymore testing with the standalone application as I don’t want the possibility of it corrupting the audio. I wish I knew what exactly is causing it–I suspect MG2 standalone but can’t say for sure. I do know that when the audio gets corrupted, it always coincides with using the standalone app.


#18

Yes, of course. Testing with standalone is perhaps out of your interest. But the quirk (hrrmm… one of the quirks) with MG2 that I think in order to upgrade to new version or especially searching or re-scanning for new or added plugins, whether it is VST or AU requires standalone mode.

Such things aren’t told about in the very brief manual and “run-through” that exists like a “hovering mouse over tips” kind of thing. It doesn’t bring up “don’t do this or that, or else…” because such things will become very negative in the end, and it will only consists of the caveat and pitfalls of the thing. But hey, they need to upgrade sometime anyway, so that’s the deal with all software: What bug wasn’t fixed now, will be fixed next time around. Or they make a priority of fixes that are worth fixing or not. No blaming Jam Origin for that, it’s all of them.


#19

Yes, this is the main culprit. How should one do it else? MG2 doesn’t follow suit, when firing it up, it resorts to some default or earlier settings of a patch or preset.