Paul said:
>which all these other issues rely. This includes the assumption thatsetting a parameter and sending a command are essentially isomorphic operations (I think not, and don't recall seeing anyone trying to treat them the same in any other system before), one aspect of which is changing the basic OSC message semantic from the original 'call a method of the receiver' to 'set a named control value within the receiver',
finally, some meaty technical issues. i think this is an issue, yes. but its definitely not without precedent in the existing applications that use OSC, and even if it was, it would be easily addressable with minor syntax changes.
.../path/to/plugin/set/parameter-name/value
> another aspect of which is the absence of any fixedconcept of a note command,
this just hasn't been fleshed out enough here. in the discussions of XAP that tim steered on the LAD mailing list, this was very, very deeply discussed and the design of it appeared to be better than any other system i can think of (MIDI, Csound, SKINI, MusicKit and so forth).
another aspect of which is the absence ofany clear idea of how the container aspect of OSC addressing (slashed path) would be used in GMPI in a way that lets any given plug talk to any other without host rechannelizing.
why would we ever want to allow such a thing?
>More pertinently, I see problems with the fundamental assumption thatplug P's state at arbitrary time T is always adequately represented by state of P's published parameters at T. That's certaily a true
i think this was asserted over a year ago. i am personally happy to revisit this if its at the heart of the issue, but i am not sure that it is. this would appear to really concern whether or not TotalRewind is possible, and i don't see TotalRewind as the critical issue (I'm not sure I even see it as an issue at all).
>A stab at it: It seems truer to say that plug state is represented byplug .storage. state than it is by plug .parameter. state. I think we already know that all memory is managed by the host. Is there no way for the plug to just get its variable & malloc()-style storage memory from the host, so to restore state the host just snapshots & restores the whole lot in one go? This way state restore is not limited to just to parameters, no need for Actors, no stored-in-two-places sync problem to fix at all. Then messages could be routed straight through to the plugs without host parsing and handled by the plugs themselves. So not constantly calling setParameterAutomated(), more like doing mallocAutomated() just at init and reconfig time.
i don't dislike this idea at all, but i suspect that steve, mike or tim will explain why its problematic :)
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
