P-MOD - Audio control signal = very unstable results.
The Min vol also lies...

maybe it has something to do/related with how the automation evnelopes in reaper works?

because the envelopes gives unstable results as well...

see here: http://forum.cockos.com/project.php?issueid=1769

btw- I just lost a good moment of creativness because of this :/

and the worst thing is that I can't even find a good workaround for this in reaper...while this is an important technic for my mixing. :/

LICEcap:

INPUT sound = one shot snare in loop.

see the input level: (very unstable.. why?)
[img]http://img822.**************/img822/9242/62923532.gif[/img]

still not confirmed?

my mix really suffer from this :/

I've never understood how you're measuring this. Do you have a demo project with some steps/information on how to see that "0 attack is not really 0"?

I will upload something soon...

Pretty simple to test, just need a click source. Here's a GIF showing exactly what Reflected was talking about:

[img]http://img831.**************/img831/666/pmbug.gif[/img]

And here's a demo project so you can see for yourself: https://stash.reaper.fm/v/6395/PM%20speed%20test.RPP

Yes, I reproduced that part some weeks ago but the issue here is "0 attack is not really 0" not "Audio control signal = very unstable results". Do you have any ideas on how to reproduce or measure this?

Thanks.

Ah, my bad. I thought that was part of the bug report. Well, maybe it is, but anyway... about the non-zero attack thing, maybe all you need is a pure impulse (1 sample at max amplitude) and see if it picks it up... I'll try that later.

https://stash.reaper.fm/v/6581/PM%20Attack.RPP
Here you go, this has a plucky synth and another synth on track one that generates short blips, which modulate the volume of the synth on track 2. Just drag the envelope down to hear the effect; it completely misses the attack of the synth.

[edit] Also, if you set the attack and release to 0 ms on the parameter modulation, it still lets sound through, yet the meters show nothing.

Now that I think of it, this is flawed because the volume slider might have some smoothing applied to it. We would need a visual on the waveform the PM is producing.

Thanks for the project.

I see you've set it to "Positive" which actually does the opposite as ducking, it determines how much of the signal is heard. In this case, with an attack of 0ms and a release of 55ms, you're telling that just a small section of the audio signal is going to be heard (first 55ms of the sound to be precise). As example, set it to "Negative" (keep it at 100%), set ReaSynth's volume back to 0dB (you may also delete the envelope lane, if you want), set the release at 90ms and crank the send level all the way up to make it receive more of those blips, now play the project. You'll see that the whole signal is ducked (-inf in this track meter) which confirms the attack is actually 0ms. You may lower the release and listen how the sound starts coming out because you're taking less of the blips, which also confirms the release is working properly. What I found interesting, in previous analysis, is the signal isn't read properly all the time. You may verify this by lowering the release to 74, slowly, using Ctrl, then increase it and set it to 85: in the way up you'll hear the sound again at a completely different level.

I attached a project with a "Negative" setting

I think I see what's going on here...

I wasn't trying to make it duck the signal, I was basically using the control signal as a gate, and seeing if it would open in time to catch the attack of the synth, which it doesn't seem to do.

In your project, with the settings you have, and the number of blips, I don't think the control signal is finishing its release phase before it hits the next blip. So, it seems like it's catching all the attacks, but really it's just stay in ducked mode because it never came back down to 0 before the next blip brings it up to full again. If you delete half the notes in track 1's midi, you'll hear a click at the beginning of every note before it ducks the rest of the signal and comes back up.

Also I think since the send amount is at +24dB, and the PM is set to max volume 0dB, the signal is staying longer above the release threshold and so it takes significantly longer than 90ms for the control signal to disappear (though I don't know exactly how it chooses when to start releasing). So even though there's a bit less than 125ms between each note (at this tempo), the signal with 90ms of release stays stuck on.

On the bright side, your idea to use ducking makes the problem even more obvious :). But again, if there's smoothing on ReaSynth's volume slider (which seems unlikely since it's not exactly Cockos' flagship product and doesn't deserve that much attention to detail) then this testing is all for nothing.

That doesn't happen here. If I delete half the notes or just keep the notes on the beat it ducks the signal properly here, no attack is missed. I wonder what's the difference here. Did you try it with lower buffer sizes? Remember it all depends on buffer sizes with Parameter Modulation, the less the best.

Even at 2ms, I still hear a brief pop at the beginning of each note. When rendered I hear them too.

http://www.sendspace.com/file/x00qpo (Apologies if the filesize is too big)

Thanks again for the project, I'll download it in a few hours. In the meantime I created a brand new project with 2 tracks and a set of kicks (with 'clicky' attacks) in both. I can confirm it is not really 0 ms and it also confirms my suspicion: ParaMod sensitivity is buffer size dependent. I've had several discussions with other users about this in the past and it's always been a known fact that it depends on how high or low you have your buffer size though I never dug too deep into this like now because it's always sounded and worked OK for me (I don't use those 'fast' attacks there). At this point I'm not sure if this issue should be set to confirmed or not because, as I said, it's always been a known fact in Reaper and that's just probably how Parameter Modulation works (though I strongly believe it could be improved somehow).

Thanks again for your time Broman, really appreciated.

[edit] The file above is just a render from the project you uploaded showing that I still hear pops so I guess since you've already confirmed that yourself there's no real reason to download it.

Yeah, I don't think it's right that it bases itself off the buffer size since that forces you to run the project at impossible latencies when it's filled with plugins if you want the best accuracy. I'm not sure what buffer size rendering uses but if it's different from the live buffer size that could complicate things further when producing a song.

It may be impossible to change the way it works without rewriting significant sections of the program, but I would at least like to hear from the devs on the matter and whether they can come up with a way to make it consistent across buffer lengths. At the very least, however, I think Reflected's idea to add a pre-delay so that it can detect more quickly would be great.

By the way, is automation affected by the buffer size as well? What does the size dictate, just how quickly values can update?

As an FR pre-comp would be very useful as well, especially for ducking.