|
|
|
08-13-2010 08:03 AM | |||
|
|||
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 :/ |
08-13-2010 08:11 AM | |||
|
|||
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. :/
|
08-13-2010 08:21 AM | |||
|
|||
LICEcap:
INPUT sound = one shot snare in loop. see the input level: (very unstable.. why?) [img]http://img822.**************/img822/9242/62923532.gif[/img] |
09-18-2010 12:26 PM | |||
|
|||
still not confirmed?
my mix really suffer from this :/ |
09-18-2010 12:36 PM | |||
|
|||
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"?
|
09-18-2010 01:27 PM | |||
|
|||
I will upload something soon...
|
09-19-2010 02:28 AM | ||
|
||
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 |
09-19-2010 09:44 PM | |||
|
|||
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. |
09-20-2010 05:00 AM | ||
|
||
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.
|
09-28-2010 11:56 AM | ||
|
||
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. |
09-28-2010 04:31 PM | |||
|
|||
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 |
09-29-2010 12:54 PM | ||
|
||
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. |
09-29-2010 01:06 PM | |||
|
|||
Quote:
|
09-29-2010 01:47 PM | ||
|
||
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) |
09-29-2010 03:34 PM | |||
|
|||
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. |
09-29-2010 05:36 PM | ||
|
||
[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? |
10-19-2010 10:09 AM | |||
|
|||
As an FR pre-comp would be very useful as well, especially for ducking.
|
Issue Tools |
---|
Subscribe to this issue |