[gmpi] Re: Reqs 3.8 Events - ramped events
- From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 25 Jan 2004 22:35:29 +0100
On Saturday, January 24, 2004 11:26 PM [GMT+1=CET],
Chris Grigg <gmpi-public@xxxxxxxxxxxxxx> wrote:
> C) If GMPI forces conversion of integer control surface values into
> real values to occur at the GMPI graph bounds (by the host), then it
> eliminates the possibility of allowing more than one plug destination
> to respond to the integer messages in different ways. Compared with
> existing plug formats, this is a loss of functionality.
Can you explain this a bit more?
>> > - In actual practice, how is the int/real conversion configured
>> for > scale & offfset etc. by the user?
>>
>> MIDI cant encode scale and offset, so it doesnt have to be.
>
> Not sure you understood my question. If I understand correctly, all
> y'all propose GMPI graphs contain & route only 'natural value'
> parameters, i.e. frequency in hz, maybe filter Q as a coefficient,
> level in dB, etc. Whereas MIDI speaks in terms of integer control
> values with in many cases no predefined mapping from control value to
> represented real value. So my question is: what is your proposal for
> where and how such conversions on incoming events from MIDI
> controllers (incl. control surfaces) are performed?
I would think the best place would be in the receiver (probably the plugin)
that knows how to interpret/convert the values, but possibly with the help
of the host in the form of standard MIDI messages to real value conversion
routines.
>> I also want the control packet for to be OSC compatible (at least at
>> a basic level), and I'm definatly not handling 3 packet formats.
>
> Maybe you and I both suffer from the "When the tool you know best is
> a hammer, all problems tend to look like nails' problem... your
> hammer is OSC, mine is MIDI. I have to say, I wonder whether there
> is broad support for OSC in GMPI.
Well, at least one of the bigger players that apparently saw the usefulness
of OSC is Native Instruments: they are using OSC in Reaktor.
>> > Unless I'm mistaken, that's for the group to decide later, when we
>>> get to setting requirements for how MIDI will/won't be handled...
>>> no? Though I have to say, some of the anti-MIDI sentiment here --
>>> not naming names -- does strike me as kind of
>>> religious/ideological/ivory-tower/anti-user.
Not religious and especially not anti-user: I know several people that
apparently do experience the limitations of MIDI and are starting to use
other ways of communication such as OSC. It's not that we don't want support
for MIDI, but just not as the base within the GMPI graph, so that the limits
are not baked in from the start.
> Not 100% sure I agree with your analysis, what do you mean by
> 'parsed'? If sysEx communication between external devices and plugs
> is going to be supported (needed for some control surfaces), then
> you'd need actual MIDI byte sequences to be able to move around
> inside GMPI graphs.
I think one of the GMPI parameter types was some kind of opaque blob of
bytes, so if you need to move sysEx things in the graph, that will not be
impossible.
Koen
----------------------------------------------------------------------
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
Other related posts:
