+ ReaTune: fix longstanding UI/audio thread locking performance issue # Automation items: add option to automatically append envelope name to automation item label # Envelopes: in automation-item-only mode, optionally restore baseline FX parameter values outside of automation items # Envelopes: fix resetting user preference for applying trim to envelope [t=195776] # RubberBand: another fix
__________________ subproject FRs click here note: don't search for my pseudonym on the web. The "musicbynumbers" you find is not me or the name I use for my own music.
# Automation items: add option to automatically append envelope name to automation item label
awesome thanks!
__________________ subproject FRs click here note: don't search for my pseudonym on the web. The "musicbynumbers" you find is not me or the name I use for my own music.
All we now need to finish the job is being able to assign custom colors to envelopes, and AIs separately.
Let's keep on using the 4 theme colors as a default, but we should be able to override them on envelope level, and then AI color should be overriding the envelope color (but by default use envelope color, of course). Perhaps an option to randomly color the envelope when created for the first time for a particular parameter (this way we avoid repeating the same 4 drag colors over and over again)?
I must admit that whilst I was naming my AIs (the reason I asked for auto naming) I also tried to see if I could colour them too.
Would be super nice icing on the cake if they could be but I don't want the devs going (more) crazy over this! lol
__________________ subproject FRs click here note: don't search for my pseudonym on the web. The "musicbynumbers" you find is not me or the name I use for my own music.
# Envelopes: in automation-item-only mode, optionally restore baseline FX parameter values outside of automation items
Great !
Is it possible to add an option to have the previous (great) behaviour ? (Outside AI, baseline FX parameter is the same than AI edges values).
Otherwise, i don't understand why it's not possible to have the same "automation-item-only mode" for volume/PAN and FX. It would be more logical and easy.
Devs... another thing mentioned a decent amount of times from 5.5 release cycle, seems simple to implement?
We still cannot drag&drop stored AI presets from Media Explorer. It would be so great if we could do that! Especially if we can also preview how the AI looks in the waveform display area.
Devs... another thing mentioned a decent amount of times from 5.5 release cycle, seems simple to implement?
We still cannot drag&drop stored AI presets from Media Explorer. It would be so great if we could do that! Especially if we can also preview how the AI looks in the waveform dispaly area.
No, no.
Drag drop is always cumbersome workflow: cause you have to move mouse from ME onto AI.
IMHO, way better would be:
Preview AI's from the window that pops up when you do "Load Automation Item"
So workflow would be:
- Select an AI in Arrange.
- Hit keycommand that you assigned to action "envelope: load automation item"
- Click on a saved AI in the appeared window.
Outcome:
Instantly, the selected AI in Arrange will be replaced by the clicked AI.
With the new default mode for baseline values outside of AIs, it would be very useful to apply the current value to the time selection, to start, to end, etc... as an AI.
Basically latch preview for automation items.
p.s. It'd be great if this worked with the envelope + AI mode too.
Enjoying the automation items now.
These are not feature requests as much as it feels strange behaviour.
1 If i have two automation items next to each other, it feels like i should be able to draw across the two items, i was trying to make the two ends match up and a ctrl+drag freehand draw across the two items would be great for fixing that up.
2 It kind of feels strange that when dragging or copy pasting an item over a previous item, it goes to two lanes, is there a pref for this that i am missing, i would prefer to just see the item dragged over the other item (I have clipping on) rather than in a second lane and then back to a single lane when i release.
Again, not feature requests, just feels strange to me personally.
__________________
Stop posting huge images, smaller images or thumbnail, it's not rocket science!
Bypass envelope outside AI + do not restore values outside AI = great
Thanks. Seems usefull.
Quote:
Originally Posted by ovnis
Is it possible to add an option to have the previous (great) behaviour ? (Outside AI, baseline FX parameter is the same than AI edges values).
Anyway, Latch behaviour option would be also good (so if I click bettween AI, I hear final render result, currently results are unexpected until play cursor goes to AI on related envelope). Even if it borns new problems (non deteministic values if no AI in the lane, conflicts with param modulation etc), I wouldn`t care about these things for this mode.
Anyway, Latch behaviour option would be also good (so if I click bettween AI, I hear final render result, currently results are unexpected until play cursor goes to AI on related envelope). Even if it borns new problems (non deteministic values if no AI in the lane, conflicts with param modulation etc), I wouldn`t care about these things for this mode.
Exactly, if using this mode then you're probably not using param mod or any of these other things, you just want a clean envelope lane that latches between AIs. For any electronic music, this would be a godsend.
"in this mode, do not restore FX paramater values outside of automation items"
If you stop the play cursor inside the AI, over an envelope value which is not the same than the AI last or first value and if after this you play outside the AI, you could be wrong for thinking that current envelope value is the same that the AI last value (or first value). Plus, it could be an issue with unexpected audio export with non expected envelope values.
For this option, why doesn't return to the previous one (outside the AI, value is the same than the AI first or last value) ?
I wonder in this new mode when trying to work with normal automation lanes.
Would it be possible to make it so that if you try and draw in automation or input a single automation point. That it can auto create an ai item?
Maybe if you say took the pencil and drew from left to right a string of points (without letting go of mouse, you would see an ai item pop up as you were doing this to contain these points and it's length would be defined by where you let go of the mouse button?
For me it would be a few steps less than first drawing in the ai container before then adding envelope points.
Maybe too crazy?
__________________ subproject FRs click here note: don't search for my pseudonym on the web. The "musicbynumbers" you find is not me or the name I use for my own music.
i'm still not liking how envelope lane behavior is being forced when my workflow would never result in invisible automation lanes due to MPL's "insert AI" script. i suppose i could make a series of custom actions that always push envelopes back into the media lane but i foresee this being a kludge. i still wish that envelopes would simply disappear when the last AI is deleted from them since i will never, ever be using automation data this is not included in an AI. ever. *much like envelopes are deleted when the FX itself is deleted.
Quote:
# Automation items: add option to automatically append envelope name to automation item label
love this ^
Quote:
Originally Posted by schwa
The problems with B have been illustrated up-thread by Mercado Negro and others. If you want the state of a plugin knob to change depending on where you click in between automation items, then effectively that knob is being automated and you shouldn't be using the automation-items-only mode.
i can make a case for B, and i absolutely should be using automation items only mode.
if you are seeking around your project but still want to land in position X and hear what it would sound like if you'd reached that point by playing from start of project, WITHOUT losing ability to control that parameter during non-AI times, you'd want case B.
case B remains the closest thing to the original FR that i fleshed out months ago and we've very very close to it. currently, B is the only thing that would truly allow deterministic seeking in project without losing control over non-AI territory OR user control over parameter in between AIs.
it'd just be one more option box for "latch last automation point on seek" and, i suppose, "latch first automation point on seek if no previous automation item exists"
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
Yes! can hear the differences but there is still a spiking issue with the transient modes there. Some of the spikes are about +15-30db..
Will have a closer inspection today at more combinations/variations.
Would be really great knowing some of what hides behind this rubberband with applied transitioning times seeming to vary.
Any chance of a description to what goes on under the hood a bit here please cockos?
Some numbers or >times to effect< are good infos.
Re: ReaPack/mpl_Insert 1 measure long automation item for last touched parameter
I expanded it to use with volume and pan envelopes by checking last action name.
thank you for this.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
text form: "on seek, always latch to last AI contained envelope point on track, unless one doesn't exist, upon which seek to next AI contained envelope point on track"
"and still do all kinds of midi learned manipulation in between them during playback, because latching to previous value doesn't make this worthless"
i believe those illustrating a "problem" with case B in the last thread don't understand the use case.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
i'm still not liking how envelope lane behavior is being forced when my workflow would never result in invisible automation lanes due to MPL's "insert AI" script.
I disagree. I think that behavior is fine by default and for majority of users (not everyone will use the same script you use). Perhaps the script could force the envelope showing in media lane in your case, then, or merge it in a custom action?
text form: "on seek, always latch to last AI contained envelope point on track, unless one doesn't exist, upon which seek to next AI contained envelope point on track"
"and still do all kinds of midi learned manipulation in between them during playback, because latching to previous value doesn't make this worthless"
i believe those illustrating a "problem" with case B in the last thread don't understand the use case.
It should work like that. It's more logical and usefull than actual behaviour.
I disagree. I think that behavior is fine by default and for majority of users (not everyone will use the same script you use). Perhaps the script could force the envelope showing in media lane in your case, then, or merge it in a custom action?
surely "fine by default" isn't the same as "the way it should be, period."
envelopes aren't in the media lane by default, and that's fine, but that workflow shouldn't be impeded
the issue isn't the script, the issue is that this change adds unnecessary steps to workflow for those of us using media lane envelopes. if someone never uses envelope lanes, and i won't, there's no getting around the fact that this is a workflow regression
a custom action/script combo might be feasible and i'm not opposed to it but all of this could be better handled by clearing envelopes upon last AI deletion as i described above. which, if i recall, you agreed with several threads back regarding deleting one of multiple stacked AIs in media lane
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
i can make a case for B, and i absolutely should be using automation items only mode.
if you are seeking around your project but still want to land in position X and hear what it would sound like if you'd reached that point by playing from start of project, WITHOUT losing ability to control that parameter during non-AI times, you'd want case B.
case B remains the closest thing to the original FR that i fleshed out months ago and we've very very close to it. currently, B is the only thing that would truly allow deterministic seeking in project without losing control over non-AI territory OR user control over parameter in between AIs.
it'd just be one more option box for "latch last automation point on seek" and, i suppose, "latch first automation point on seek if no previous automation item exists"
Nice pic!
Anyway to me case B is like non-deterministic because if after playing an AI-3 I move the cursor to another non-AI space which is NOT right of AI-3, the value would not reflect the lafthand AI
Best solution would be C-like: a kind of "default" value that is the value that the knob had before adding AI and that get's changed when I modify the knob not in latch,write,etc. mode. So in AI the param gets AI value, outside AI it gets the knob value that you last changed/set.
Workflow example: Frequency value is at 3khz. I add 3 AI on that parameter and play with them. Outside AIs value gets back to 3khz unless you touch the knob in normal TRIM mode. The default level could be shown if evn lane is visible or else one can see it from the knob itself.
it's mpl's pic i just resurrected it into this thread
Quote:
Anyway to me case B is like non-deterministic because if after playing an AI-3 I move the cursor to another non-AI space which is NOT right of AI-3, the value would not reflect the lafthand AI
that's not what case B advocates, though. see the other picture that i posted later. case B advocates looking at the most recent AI, seeing the last envelope data point, and latching that on seek. if no previous AI exists, ie seeking to the beginning of the project, it looks at the NEXT AI and uses the FIRST envelope data point.
totally deterministic, without losing the ability to freely control the parameter when not contained within an AI's bounds.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
text form: "on seek, always latch to last AI contained envelope point on track, unless one doesn't exist, upon which seek to next AI contained envelope point on track"
"and still do all kinds of midi learned manipulation in between them during playback, because latching to previous value doesn't make this worthless"
i believe those illustrating a "problem" with case B in the last thread don't understand the use case.
This this this. I can't possibly imagine a case where it's any other way honestly. The idea that just because you stopped the playhead on the 'wrong' area will make your project sound different is absolutely crazy to me, and that's what a lot of people are pushing for some reason. I don't get it!
This this this. I can't possibly imagine a case where it's any other way honestly. The idea that just because you stopped the playhead on the 'wrong' area will make your project sound different is absolutely crazy to me, and that's what a lot of people are pushing for some reason. I don't get it!
it's a different expectation coming from a different workflow. as such, i don't really get it either, but all of this functionality doesn't have to compete if we are given another option in prefs for case B as shown above.
edit, i think it's still stemming from this idea of a persistent, UI defined "baseline" rather than deterministic reference points creating AI-determined "floating baselines" in between AIs. the latter is what case B advocates.
__________________ mccrabney scripts: MIDI edits from the Arrange screen ala jjos/MPC sequencer
|sis - - - anacru| isn't what we performed: pls no extra noteons in loop recording
| - - - - - anacru|sis <==this is what we actually performed.
# Automation items: add option to automatically append envelope name to automation item label
May I suggest to have a look at the spacing of the AI labels with non-default themes (better: fonts) like I posted in one of the prerelease threads before: https://forum.cockos.com/showpost.ph...5&postcount=57
That would be really nice.
Found this as well while checking rubberband modes
Apologies to post again--but just thinking the quicker stuff gets noticed=quicker fixes may come (eyes crossed.)
Noticed how rex peaks are also still not being made--quite bizarre(glue fixes that.)
Not a showstopper just a dripdropper atmo. =)