Maximum VST2 parameter counters?

[mystran]

I know this has been discussed in some random threads, but I can't possibly remember the conclusions nor can I find it right now...

So... does anyone know if there is some practical advice with regards to: How many parameters one should expect to be able to export, roughly? How many parameters one should expect to have automation working in an average host, roughly? I know some hosts don't care, but I wonder if I export something in the range of 4k-8k parameters, do some hosts refuse that kind of stuff?

edit: what I'm working on doesn't STRICTLY require automation for that much stuff, but I figured it could be cool.. assuming there's any hope that it'd actually work..

[AdmiralQuality]

MAXINT!

[Richard_Synapse]

Most hosts should handle large parameter counts gracefully, as there's some plugins I know of that use them. The handling of the automated parameter list will be a nightmare for the user, however- if the parameters work / are displayed at all, that is.

To give a number, I'd try to stay <= 1000 parameters.

Richard

[AdmiralQuality]

This sounds like a worthy research project, mystran. Why not test out the popular hosts and let us know what they do with huge numbers of parameters, and what the limit (if any) for each host actually is?

[mystran]

This sounds like a worthy research project, mystran. Why not test out the popular hosts and let us know what they do with huge numbers of parameters, and what the limit (if any) for each host actually is?

Maybe I'll do that. There's the pain of potentially having to maintain two version though.

[AdmiralQuality]

This sounds like a worthy research project, mystran. Why not test out the popular hosts and let us know what they do with huge numbers of parameters, and what the limit (if any) for each host actually is?

Maybe I'll do that. There's the pain of potentially having to maintain two version though.

Well, it'll let you know what the lowest common denominator is and you could then settle on that. Though, as Richard points out, I think practicality to the user will be the limiting factor long before the host gives out. Still, I'm definitely curious to know. Might whip one up myself just to see what happens, should only take a few minutes.

[mystran]

It's an all-or-nothing situation for me I'm afraid. Either I export around 4k parameters or I don't. I tried a less spammy solution but it just runs into a huge mess in practice.

[AdmiralQuality]

Well, I think if you have 4k parameters then you owe the user an interface that enables actually handling them in some organized way. So maybe practicality isn't an issue (unless you're really expecting people to record and edit 4000 automation envelopes on a single track! ).

[mystran]

Ok, so basically I suppose I can probably tell what I'm up to: I'm doing a sort of pattern sequencer thingie (not quite, but that should give some kind of context anyway), and I'd basically love to make all the pattern data something you can automate. Ofcourse you wouldn't do that manually per-parameter, but point is you could record changes on the fly.

This would be work fine, if it wasn't for the fact that it totally doesn't work together with pattern selection automation (which I consider more important, given rest of the design), unless every pattern exports separate parameters (host automation is just too unpredictable in practice; I tried and it's a huge mess).

So not only do I have an unreasonably large number of parameters, but I would also like to multiply it by the number of patterns (where around 16 is probably the reasonable minimum). Like I said it's not critical feature, rather just something that would be kinda cool.

PS: note that I'm already encoding (combining parameters) the actual data in a way that makes it pain to manually edit... because otherwise the parameter counts would just get silly... so mostly it's just "replay edits" feature that I'm considering.

[antto]

i wouldn't want the pattern data to be automatable
in my sequencer it's even hidden (non-automatable)
you can select different patterns while playing (thus you can automate this)

mystran: you're up to something.. ;]

[AdmiralQuality]

My guess was giant additive synthesizer.

[mystran]

i wouldn't want the pattern data to be automatable

Depends on the pattern data.. but maybe I'll give that up.

[mystran]

My guess was giant additive synthesizer.

Nah. Additive synths suck. [edit: not entirely serious; I do use them occasionally; just not something that interests me...]

[AdmiralQuality]

My guess was giant additive synthesizer.

Nah. Additive synths suck. [edit: not entirely serious; I do use them occasionally; just not something that interests me...]

But what if they had 4000 real time automatable oscillators?

I actually hope to do one someday, hybridized with some other techniques. Always working on it in the back of my head. Interface is the biggest challenge, how to manage enough operators to make it powerful enough to be worthwhile?

[camsr]

R&D.

but seriously, I would not even want to LOOK at 4000 parameters, much less 200.

The situation sounds like a giant music studio, with 10 knobs on each piece of gear, with over 100 pieces of gear.

Which begs the question, how many parameters actually need to be used at any given time?

If you have a design philosophy, you can architect a sub automator for one macro parameter, which has pre-defined behavior. Musically useful. Doing this might be able to reduce the number of parameters by a factor of 2 or more.