VST automation

lalo · 30 May 2005

buump..opinions?..ideas ..suggestionz? 😀

stefan · 30 May 2005

Most people most likely agree 🙂

platinumears · 20 Jun 2005

stefancrs wrote: Most people most likely agree 🙂

I know I do! 😉

Is this possible yet? I can't seem to find a way..

Dan 🙂

beno · 20 Jun 2005

I'm pretty sure it is already possible. I think it is the preset parameters are also automatable. Is this correct? Ben

malc · 20 Jun 2005

Yeah, that's right Ben. You need a Preset Manager and then a Preset Parameter component for each parameter you want to automate.

We might change have to change this system to make it more flexible.

Shifrin · 20 Jun 2005

Funnily enough I was just playing with this yesterday, managed to make a very simple 'gain' plugin with (you guessed it!) automatable gain 🙂

Shif.

platinumears · 22 Jun 2005

Well, I got this to work, but I had to modify the standard knob to get it to redraw properly while being automated.. or did I miss something?

Dan 🙂

Shifrin · 23 Jun 2005

Not sure about the standard knob, but I don't remember having to do much when I added the preset/parameter automation to my own knobs - which automate and update fine in EnergyXT. Then again maybe the standard knobs don't work in the same way as my own 😉

Shif.

malc · 23 Jun 2005

Hi platinumears,

The standard knobs don't force redraws when preset parameters change. If you go into the Knob Control module and hook the output from the Preset module up to the trigger on the Redraw Aread then it should work.

The problem is that if you use automation to make continuous changes like sweeping filter cutoff say then you might find that the redraws generated sap enough cpu to affect the audio. Give it a try and see what happens. I have this down as something I need to re-visit.

One possible solution might be to use a Tick 25 to shecdule redraws when a parameter is changing, this would keep the number of redraws down to a maximum of 25 per sec.

Let me know if any of this works or not.

Tom7777 · 23 Jun 2005

Well automation has got in the way with redraws for me before and theres no way to fix it at all unless its a bug, if you make fast changes to controls the redraw will pause/lag if you are constantly moving a control, even if this control if not linked to the redraw and its just a tick25 constantly redrawing the area there is no workaround to fix it and believe me i have tried.

Im probably speaking about something slightly different though so i may have to send you another .osm example sometime but its a similar thing.

platinumears · 23 Jun 2005

malc wrote: hook the output from the Preset module up to the trigger on the Redraw Aread then it should work.

Thats how I did it I think.. it seemed to work ok, but haven't used it in anger yet..

malc wrote: The problem is that if you use automation to make continuous changes like sweeping filter cutoff say then you might find that the redraws generated sap enough cpu to affect the audio. Give it a try and see what happens. I have this down as something I need to re-visit.

One possible solution might be to use a Tick 25 to shecdule redraws when a parameter is changing, this would keep the number of redraws down to a maximum of 25 per sec..

I'l try that out and let you know how I get on. Thanks!

Dan 🙂

lalo · 23 Jun 2005

malc wrote: The problem is that if you use automation to make continuous changes like sweeping filter cutoff say then you might find that the redraws generated sap enough cpu to affect the audio. Give it a try and see what happens. I have this down as something I need to re-visit.

ouchh...i'll give a try when i'll have some free time (no free time until july 🙁 ) ..seems a thing to watch out

malc wrote: One possible solution might be to use a Tick 25 to shecdule redraws when a parameter is changing, this would keep the number of redraws down to a maximum of 25 per sec.

this could be a solution..cause we watch movies at that rate 😉.. anyway i noticed that timers tends to use a lot of cpu compared to their functionality...if i remeber well ..malc or jorge said that this is an area wich will be under examination in the future...

lalo

Tom7777 · 23 Jun 2005

This could be a solution..cause we watch movies at that rate 😉.. anyway i noticed that timers tends to use a lot of cpu compared to their functionality...if i remeber well ..malc or jorge said that this is an area which will be under examination in the future...

Malc is looking at the Timer modules, i think he was re-coding them so they work better 🙂

lalo · 5 Jul 2005

malc didn't find a solution (yet) ..keep hopin' for the future 🙂

lalo

Tom7777 · 6 Jul 2005

Yeah it looks like the timers will remain the same for now 🙁 ahh well