Parallel processing question.

[Stranger.]

I honestly have no idea what you're talking about here, as I've found the VGM-01 to be incredibly useful - there is literally no other way to accomplish what it can do in Reason! Either you're exaggerating for effect, or you're doing things I've never heard of doing before (wouldn't be the first time for either!).

Maybe you could back off the hyperbole for a bit and explain what it is you're trying to do when you run into this issue?

Lol- there is no hyperbole(as you put it.) and yes,i may be doing things you never have before... so..yeah w/e.
The VMG is 1 of the most convoluted units i've come across in practice.
It gives inconsistant results even if following developers instructions of use,and them results are only taking a static measurement after insertion.
It by definition will "respond to specific DB values" and them DB values are within a very limited range- -14/-20db is'nt it?
How is your 'average user' going to know what DB a certain unit puts out?
This is REason,not rocket science m8.

In practice I'd suggest putting the change in latency exactly where you enable that other plugin in the chain you compensate for..

Another convoluted response normen..
TBTH- that unit will not solve problems that is obviously an issue within the programme itself.If it does not respond in a 'dynamic updated way' what's the point of using it?,if certain parameters change latency values.Eh?

no plugin I know of has variable processing latency.

Then your 'knowledge' is also incomplete young man.

I did not come here to argue,just made some observations that others may be overlooking..?
Good day to you.
Rating=0.1

[Exowildebeest]

From what I remember, there are several RE's with variable latency. The Softube Saturation Knob for instance, is something like either 3 or 4 samples. That can indeed be a problem when you automate it and this latency changes.

However, there is no possible way for the VMG or any device really to fix that, for (at least) 2 reasons:

- It can never measure a device's latency constantly if the device in question is already fed another signal

- If it "adapted" latency automatically, to whatever automatic measurement, or if you do it by automating it yourself for that matter, you might get clicks/audio artifacts

The fact of the matter is that the VMG requires the user to do some work. If you're changing settings on your parallel channel, you might need to re-measure. Fact of life.

[normen]

Lol- there is no hyperbole(as you put it.) and yes,i may be doing things you never have before... so..yeah w/e.
The VMG is 1 of the most convoluted units i've come across in practice.
It gives inconsistant results even if following developers instructions of use,and them results are only taking a static measurement after insertion.
It by definition will "respond to specific DB values" and them DB values are within a very limited range- -14/-20db is'nt it?
How is your 'average user' going to know what DB a certain unit puts out?
This is REason,not rocket science m8.

Another convoluted response normen..
TBTH- that unit will not solve problems that is obviously an issue within the programme itself.If it does not respond in a 'dynamic updated way' what's the point of using it?,if certain parameters change latency values.Eh?


Then your 'knowledge' is also incomplete young man.

I did not come here to argue,just made some observations that others may be overlooking..?
Good day to you.
Rating=0.1

Some devices cause so much phase shifting that you can basically decide for yourself what the "right" latency might be, e.g. this is the wideband test signal of the VMG and what the Reason BV512 filterbank makes from it:



Thats when you get "inconsistent" results, same for devices that cause a shift that is actually between two samples (like some Softube devices). If you get no results you simply need to up the output of the device you measure, theres no "limited range", just "too low to measure" - no need to know any dB values, I just put the info in the manual for reference purposes.

So the only Reason plugin I know that changes its latency based on settings (apart from the compressor lookaheads I mentioned) is Ozone which has different latency per limiting type. But I don't think that would be something you typically change dynamically. If you, "old man", were so kind and pointed out other devices I missed that actually have different processing latency when parameters that are usually automated change..? Then your posts could actually have a constructive value, see I need to understand your points to actually do something about whatever issues you have.

[JNeffLind]

A note to a lonely stranger: Hijacking a thread is sometimes unavoidable. I've been guilty of it myself. Being a dick is more avoidable, but again I've been guilty. Hijacking a thread while being a dick is a solid double whammy of douchery though. Please refrain from the dreaded double whammy douche.

[Stranger.]

no plugin I know of has variable processing latency.

So the only Reason plugin I know that changes its latency based on settings (apart from the compressor lookaheads I mentioned) is Ozone

Hmmm..seems like a perfect contradiction to me,which is why i won't take this any further (i was going to video,make full notes etc etc etc),but your response tells me i would just be wasting time & resources doing that.
Fact is,if you actually run some basic tests as a developer,(or any user that 'owns' that device)-would have to admit that the points are totally valid.

Your also admitting that the manual you provide is 'incomplete' and basically not to be followed to the letter.. certain manufacturers make manuals as a precise technical specification & operation of said product,which in this case appears not to be so...

Now-

A note to a lonely stranger: Hijacking a thread is sometimes unavoidable. I've been guilty of it myself. Being a dick is more avoidable, but again I've been guilty. Hijacking a thread while being a dick is a solid double whammy of douchery though. Please refrain from the dreaded double whammy douche.

Should i take this post as a direct insult to my persona? My tag here may be Stranger,but there is nothing lonely about that pal.
Seems to go against forum rules *cough* --

I tried to help you by providing a link,not Hijack this thread,there's nothing forced about it at all--just trying to make other users aware that when the VMG is used in a parallel,or any other situation-things can be completely not as expected.
Who needs to back off here?

I won't return to post if this is the attitude here.

[normen]

Hmmm..seems like a perfect contradiction to me,which is why i won't take this any further (i was going to video,make full notes etc etc etc),but your response tells me i would just be wasting time & resources doing that.
Fact is,if you actually run some basic tests as a developer,(or any user that 'owns' that device)-would have to admit that the points are totally valid.

Your also admitting that the manual you provide is 'incomplete' and basically not to be followed to the letter.. certain manufacturers make manuals as a precise technical specification & operation of said product,which in this case appears not to be so...

1) I am not disagreeing with you, I say that these are the only examples I know of. You don't want to point me to other examples so I have to assume you don't know any others either - hence I'll continue to believe that theres no plugins that change their processing latency randomly. Which makes your statement a self fulfilling prophecy.

2) I said that the manual contains *more* information than some people might be able to stomach without believing that the device is complicated - which it in fact isn't. The manual doesn't say anything thats not to be followed. Again, it just says that if you don't get a reading you have to up the output of the device you measure, then gives detailed information about why that is so and what the minimum level is.

Why is it that you don't want to be helpful here? You complain about the state of things but you neither want to give the information you supposedly have nor do you want to explain what your actual problem is..?

[mcatalao]

TBTH-the VMG is flawed,quite horrendously--- it will NOT compensate for any 'live or automated' adjustments in a mix.
Sorry Normen,but you NEED to make that unit FULLY automatic per sample,to really make it usefull'.

I'm curious as to what devices you've found that have different latencies while automating.
I understand at different modes, a processing device might have a different latency ampunt but it has to be a heck of a functional difference to change the whole behaviour of the device.

I think, for example, if you simply automate a compressor's threshold, there isn't a change in latency. And until now, on the devices i tested, main parameters keep same latency values measured by VMG-1, and i've tested a bunch. I also woud not jump Neptune's modes on and off, or change lookahead settings over and over. These are the kind of stuff that you set up and leave it alone.

I'm also not seeing how would you compensate for live adjustments with VMG-1, since it must be inserted in the source channel rather than in the parallel (this assuming the paralel channel is the one with latency prone device). What i mean is, there is nothing to adjust to, since it happens in the other channel.

[mcatalao]

Normen, i think Neptune has a huge latency difference depending if you select normal mode, live mode and vibrato mode.

Still i don't think these are parameters to be toggling on and off and automate along a song... (maybe the vibrato at most).
And then again, neptune is not one i would use in a paralel channel normal use.

So i'm really finding it hard to perceive this as a real issue?

[normen]

Normen, i think Neptune has a huge latency difference depending if you select normal mode, live mode and vibrato mode.

Still i don't think these are parameters to be toggling on and off and automate along a song... (maybe the vibrato at most).
And then again, neptune is not one i would use in a paralel channel normal use.

So i'm really finding it hard to perceive this as a real issue?

Right. But as you say - none of these are things you'd typically change dynamically.. If you do the easiest way would probably be to simply have two VMGs that you switch between when you switch the effect. By definition switching such parameters during a performance would cause dropouts / "jumps" in the audio though.

All in all I get the feeling this is more of a personal thing than actually about the plugin or any actual problem. Case closed

[selig]

Indeed, Normen. I'm still open minded on the issues, but the total lack of examples leads me to believe both our comments still stand. Anyone got examples of how VMG is "horrendously" (or otherwise) flawed in regards to not being able to compensate for any live or automated adjustments in a mix?


Sent from my iPhone using Tapatalk

[JNeffLind]

Should i take this post as a direct insult to my persona? My tag here may be Stranger,but there is nothing lonely about that pal.
Seems to go against forum rules *cough* --

I tried to help you by providing a link,not Hijack this thread,there's nothing forced about it at all--just trying to make other users aware that when the VMG is used in a parallel,or any other situation-things can be completely not as expected.
Who needs to back off here?

I won't return to post if this is the attitude here.

I was just pointing out that you were hijacking the thread and coming off as a bit of a dick. If you can't see that then I'm not going to argue with you. One can interact and debate without pettiness or getting your hackles up.

Seems like you're calling me pal, but then saying you don't like my attitude. My context clues tell me that you're using sarcasm and again being a dick while masquerading as a nice guy. As for your cough, maybe you should get that checked out. As for your persona, not sure if this is faux intellectual speak or if you don't understand what that word means, but persona most generally refers to an adopted or acted personality in a specific given context, e.g. a character in a play, a newscaster on air, etc.. Only in the lofty latin "persona non grata" is persona used to mean "person."

Your input is appreciated. You seem you like have a better handle on some of this stuff than I do. I hope you stick around and share your knowledge. Just maybe alter your approach to interaction a bit.

[gak]

I'm not a minutia oriented guy.

Does Norman's little device work or not?

[selig]

I'm not a minutia oriented guy.

Does Norman's little device work or not?

Works like a charm for me, and there's nothing else I'm aware of in Reason to deal with the issues the VMG-01 addresses.

[gak]

Awesome. I'll demo this weekend

[mcatalao]

I've found it utterly bizarre in reason. In fact, it's one of few real complaints I have. You should be able to set it up on one of the sends and control it that way, but that doesn't seem to work as well*. That is how I did it in every other host. Now the softube FET has it's own and that seems to work pretty well.

FWIW, having a combinator with a 14:2 seems to be the best route.

*The one exception being the MCDSP 670 which seems to be a beauty. The FRG/MOO, not so much. Strange to me.

To each is own. Maybe other softwares do not have limited sends, but reason only has 8. They exist to work upon layers of multiple channels and if you use them for paralel processing you loose that ability. There isn't (at least that I know of) any latency compensation in these channels also.

[gak]

Ok. I'm too stupid to understand this.

The FET has 4 samples latency allegedly which means it has to be compensated somehow. Have no idea WHERE to do that (even with Normans device)

I thought I was following instructions so guess not?

[selig]

Ok. I'm too stupid to understand this.

The FET has 4 samples latency allegedly which means it has to be compensated somehow. Have no idea WHERE to do that (even with Normans device)

I thought I was following instructions so guess not?

If the FET is on one parallel track, you need to match it's delay of 4 samples on the other - so you put the VGM-01 on the OTHER parallel track so the total delay of BOTH parallel channels is exactly the same. Make sense?

Before VMG-01 the only way to accomplish this was to use TWO of each device, one on each parallel channel, and only set ONE of them to compress. SOME devices (including the FET) impart their delay even when bypassed, some do not - on the ones that DO, you can leave one in bypass and the other engaged.

But it should be obvious that the downside to using this approach is double the CPU hit.

[gak]

Ok. I'm too stupid to understand this.

The FET has 4 samples latency allegedly which means it has to be compensated somehow. Have no idea WHERE to do that (even with Normans device)

I thought I was following instructions so guess not?

If the FET is on one parallel track, you need to match it's delay of 4 samples on the other - so you put the VGM-01 on the OTHER parallel track so the total delay of BOTH parallel channels is exactly the same. Make sense?

Before VMG-01 the only way to accomplish this was to use TWO of each device, one on each parallel channel, and only set ONE of them to compress. SOME devices (including the FET) impart their delay even when bypassed, some do not - on the ones that DO, you can leave one in bypass and the other engaged.

But it should be obvious that the downside to using this approach is double the CPU hit.

Yes, but I had to watch eauhm's viddy first. Why I didn't just do that in the first place is beyond me.

Here it is in case anyone else doesn't get it:

[Stranger.]

All in all I get the feeling this is more of a personal thing than actually about the plugin or any actual problem. Case closed

Ok.This is absolutely nothing personal other than your the maker of that VMG unit,sorry if 'i' appeared a bit forward...
I just found some issues with certain measurements and think you could take another look at making some advancements with your RE if you can also find any inconsistant results with any other units,starting with stock devices..?

Actually in the process of *this* topic i have learned a great deal,both personally and technically,so i guess thanks to all for that!

I may share a new 'parallel method' here, which i think has many advantages over other usual practices within REason and it's 'mixer' !
Cheerz.

[JNeffLind]

I may share a new 'parallel method' here, which i think has many advantages over other usual practices within REason and it's 'mixer' !
Cheerz.

That's the spirit. I'd love to hear any tips you might have, as I'm sure others would as well.

[Stranger.]

There is the NNXT- !
This ( i find) works great recorded audio.
The trick is to take your mono or stereo files and mix them in the sampler using layers.
You have 16 'mono' outs or 8 stereo ok,but the sampler outputs in pairs 1/2,3/4,5/6 etc..
You can route these direct into the master bus returns,and this gives great control with levels and pans etc.
The sampler has spread control/pans/amp and mod envelopes-will can all be used to good effect by layering duplicate files.

Eg, take a stereo file-make it a group-and duplicate it 1 time,make that new copy another group (this gives better control per sample/layer.)
Basically you use the sampler as a 'compositor' using the filter sections on the layers,and blend them outputs at the master return section.

I find them filters actually different to the main mixer's section,and doing it this way,you can also bus to seperate mixer channels and use all them eq's and mixer settings on top! This gives a lot of scope!

Once you play with the layers and pans etc,you'll find the extra filters & resonance that you can get in the sampler far exceeds the mixer alone,and it can all be shaped by envelopes and lfo's!! GG.


I still have a problem with phase in REason,and hope some people can help me here..
If anyone's interested in solving this,preferably with the VMG.

I have to give a warning about the file,because it's dealing with extreme levels of db if any dials are touched!
I think selig and a few others here may find this interesting,but i would like to know how to fix it.!?

Looking for a perfect null here.

Play with the 'soft clip button',and width to begin,then the attacks on the maximizer--be careful of db!

File was made in 6.5,just stock. --> https://drive.google.com/open?id=0B5T_Y ... HJsN3NfRlk
PM,if any better.Thanks.

[Stranger.]

Wow..! not 1 ply?!
I thought this is where the cv eggsberts were! ??
If anyone can help,that will be much appreciated.

Maybe others don't understand what points i would like to try and make here...

[selig]

Wow..! not 1 ply?!
I thought this is where the cv eggsberts were! ??
If anyone can help,that will be much appreciated.

Maybe others don't understand what points i would like to try and make here...

A perfect null requires two things: perfect time alignment (phase) and perfect level alignment. In this case the time alignment is fine, it's the level alignment that is off. The problem is that it is off by hundredths of a dB, and there are not any Reason devices that let you get that fine of a level adjustments. I can get it a bit closer using Selig Gain (null down to - 50 dBFS, vs your null to - 4 dBFS), which has one tenth of a dB adjustments, but still not perfect (which is how I conclude I need finer adjustments). Using a slow LFO to modulate the channel fader level by CV shows that it DOES null as it passes through the correct level

This is one of those Reason "issues" that would bother a scientist but not a musician IMO!

Another issue to consider is that a dynamics device is by it's very nature non-linear with regards to level. If it is compressing to any degree you will never get a perfect null. Not that I'm thinking that's what's going on in this case, but something to consider.

Just curious what your end goal is with this setup? And for whatever reasons, you CAN get RE compressors to null perfectly when not triggering compression. The McDSP comps are one example (I chose them because they introduce no latency).

[Stranger.]

In this case the time alignment is fine, it's the level alignment that is off. The problem is that it is off by hundredths of a dB, and there are not any Reason devices that let you get that fine of a level adjustments.

You are wise selig but are you sure it's a db mis-alignment or time?

The point i'm trying to make is the maximizer is a stock device which was,i thought, zero latency without the lookahead.
In practice the moment that limiter switch is toggled with the input set at 0-the phase begins--the unit does not have the amount of -db to allow cancellation at 'usual levels',unless i'm missing something.. (i'm guessing it's left/mono channel related on a deeper level)

This is why REason (IMTHO) can lack clarity,punch and introduces the 'hollow effect' (phase),when -goto devices- make that so.. bummer.
In that example you basically have a chicken and egg scenerio-because the VGM cannot compensate-or again,am i missing something here??
That unit was bought specifically to deal with such problems,but they persist without some frankenstein workaround..sigh.

1 bonus to making the file,was the fact the 2 channels actually become a "mid-side mixer" with inverted faders!--when you pull the width of 1 channel to center-- you can get gain both going up and down on the faders!!

I guess it's an issue that i need to get deeper with,or just let go and move on elsewhere it don't happen like this....
Thanks for your input.

[Stranger.]

Just for YI selig- i get a peak @ 0.000004 with a noise floor of -132db in REAper.!
That's what i call "tighter than a nuns...."
Big difference in db per 0.000000 value!