RE: [Linuxsampler-devel] LinuxSampler control protocol (initial draft)

[Bonilla-Toledo, d. (DPS_MOLR1.1) <bon...@hp...>]

Hi,

Wouldn't be faster ( for performance ) to use API and MIDI than a
network protocol?

If the goal is to be able to control a rack mounted linux sampler, from
somewhere else, there are already MIDI controllers for that purpose.

If the GUI is built with the rest of the code (with QT) , one could just
have the code send events through API to the GUI and have the GUI update
the position of knobs, sliders etc, based on what it receives.
That would also make it easier to have the code update the GUI when MIDI
control messages are received.

As an hypothetical example, if I had a slider in the GUI to control the
Master volume

#define MIDICONTRO_OUT_ENABLED 1

int whatver_the_main_volume_is_for_gui =3D 99;

...

    QSlider * slider =3D new QSlider( Horizontal, this, "slider" );
    slider->setRange( 0, 127 );
    slider->setValue( get_current_mastervolume_orwhatever() );

...

And then the API could be something like:


int get_current_mastervolume_orwhatever()
{
if (MIDICONTROL_OUT_ENABLED){
// Have an API that echoes changes to the MIDI output.
// 1st arg midi control message and second arg is midi cc value. That
way the MIDI bus get whatever change was made.
Send_msg_to_midi_out ( 17 , whatver_the_main_volume_is_for_gui );=20
}

return ( whatver_the_main_volume_is_for_gui );
// will return the integer to set the position of the slider in the GUI.
}


Or something like that.
And then doing something similar to parse the MIDI in CC changes to the
GUI.

You could use a remote25 to control the sampler real-time and have a
sequencer record your performance. Just like a hw sequencer would.

How's that sound?

-Dave-

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of Rui
Nuno Capela
Sent: Wednesday, December 31, 2003 5:20 AM
To: lin...@li...
Subject: Re: [Linuxsampler-devel] LinuxSampler control protocol (initial
draft)


Christian Schoenebeck wrote:
>
> Here is the promised initial draft for the LinuxSampler control=20
> protocol:
>
>
http://www.linuxsampler.org/api/draft-linuxsampler-protocol-00.pdf
>
http://www.linuxsampler.org/api/draft-linuxsampler-protocol-00.rtf
>
> I expect you to post your suggestions for improvements / corrections=20
> for the protocol. Sorry that I've not created a plain text version=20
> yet.
>

ACK, read and assimilated :)

My early comment would go on future extensibility. Thus the general
command syntax should be rather be a litle more consistent, e.g.

   GET ENGINE {INFO|<engine-param-name>} <engine-name>
   SET ENGINE <engine-param-name> <engine-name> <engine-param-value> ...

   GET CHANNEL {INFO|<channel-param-name>} <channel-number>
   SET CHANNEL <channel-param-name> <channel-number>
<channel-param-value> ...

Some engine or channel parameters might be read-only (GET), others
read-write (GET|SET). The INFO instruction would return the CRLF
separated list of read-only parameters, either for the given ENGINE or
CHANNEL respectively.

Note that on GET CHANNEL commands the <channel-number> is specified
_before_ the <channel-param-value>, which leaves open the possibility to
an array or ordered series of parameter values (look above at the
intended ellipsis notation).

IMHO this leads to a more uniform and structured syntax that leaves open
every other parameter one will come about in a near future--quite
unavoidable isn't it? :)

Accordingly, some notification events would take some general format:

   CHANGE ENGINE {INFO|<engine-param-name>} <engine-name>
   CHANGE CHANNEL {INFO|<channel-param-name>} <channel-number>

I hope you get the picture.

That was my EUR0.02 :)

CU-l8er
--=20
rncbc aka Rui Nuno Capela
rn...@rn...


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's Free Linux Tutorials.  Learn everything from the bash shell to sys
admin. Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Linuxsampler-devel mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel