Re: [LAD] Linux-audio-dev Digest, Vol 49, Issue 16

> I'd be interested to hear how various projects handles this internally, if
> anybody wants to chip in?

In mine, each parameter has two additional members:
- controller_id (32 bit int)
- SYSEX string. (for SYSEX based automation).

Controller ID is several sub-fields. The high order 8 bits are the type of
MIDI message...

        enum EcontrollerType{
                Learn=-2,
                None=-1,
                NullType=0, // ignore.
                CC = 2,
                RPN,
                NRPN,
                SYSEX,
                Bender,
                ChannelPressure, // monophonic aftertouch.
                BPM,
                TransportPlaying,
                SongPosition,

                Pitch = 19, // only polyphonic allowed after here. see
ControllerType::isPolyphonic().
                Gate,
                VelocityOn,
                VelocityOff,
                PolyAftertouch,
                Trigger,
                Active, // note-stealing. float. Active (10) = not stolen.
0.0 - Voice in rapid-mute (steal) phase.
                unused1, //Reset, // int. Voice assigned new Voice ID or
re-used after period of inactivity, kill any residue of previous use. poly
ADSRs need reset to zero, filters/delays need clearing.
                VirtualVoiceId, // int. usually same as MIDI note number.
        };

..The next 24 bits identify the CC, RPN, or NRPN number (if relevant). With
polyphonic controllers, like poly-pressure, the key-number gets squeezed in
there too.

SYSEX string is for SYSEX controllers, it's just a unsigned char array
containing the SYSEX string with imbedded 'format specifiers' at the
'variable' parts. E.g. "FO 41 10 42 12 VV F7" ..."VV" being the value that
changes.

This system, AFAIK, handles MIDI automation for pretty much any type of MIDI
event.

Best Regards,
Jeff

> -----Original Message-----
> From: linux-audio-dev-bounces@email-addr-hidden [mailto:linux-audio-
> dev-bounces@email-addr-hidden] On Behalf Of linux-audio-dev-
> request@email-addr-hidden
> Sent: Thursday, 24 March 2011 1:00 a.m.
> To: linux-audio-dev@email-addr-hidden
> Subject: Linux-audio-dev Digest, Vol 49, Issue 16
>
> Send Linux-audio-dev mailing list submissions to
> linux-audio-dev@email-addr-hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
> or, via email, send a message with subject or body 'help' to
> linux-audio-dev-request@email-addr-hidden
>
> You can reach the person managing the list at
> linux-audio-dev-owner@email-addr-hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audio-dev digest..."
>
>
> Today's Topics:
>
> 1. Denemo is searching for a student for the Google Summer of
> Code (5000$) (Nils)
> 2. MIDI maps : C++ functions (Harry Van Haaren)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Mar 2011 23:45:44 +0100
> From: Nils <nils@email-addr-hidden>
> Subject: [LAD] Denemo is searching for a student for the Google Summer
> of Code (5000$)
> To: linux-audio-dev@email-addr-hidden
> Message-ID: <20110322234544.14c881d8@email-addr-hidden>
> Content-Type: text/plain; charset=US-ASCII
>
> Hello list!
>
> Google Summer of Code (GSoC) is a global program that offers student
> developers stipends to write code for various open source software
> projects. A participating student gets 5000$ for ca. three months of work.
> [Link 1]
>
> Denemo is participating and we would like to encourage possible students
> to contact us through our mailinglist [see attached link 2] or #denemo on
> irc.freenode.org.
>
> Our top priority project is the following, but we are also ready for
> student ideas.
>
> "Make midi/audio output realtime-capable
>
> Denemo creates MIDI messages to use them with its internal Fluidsynth-
> sampler or send them out via the Jack Audio Connection Kit. This procedure
> is not realtime-safe yet. Graphical computation and controlling Denemo
> during playback creates playback-glitches. In order to fix this the
> midi/audio subsystem should run in its own realtime-thread and get
> priority. Needed student skills: Programming in C, experience in threads
> and realtime programming. Useful: Knowledge of MIDI and the Jack Audio
> Connection Kit."
>
>
> Links:
> [0] http://www.denemo.org
> [1] http://www.google-melange.com/
> [2] http://www.denemo.org/index.php/Community
> [3] http://www.gnu.org/software/soc-projects/ideas-2011.html#denemo
>
> P.S.
> If you are not a student feel free do contact us anyway and help Denemo
> like the rest of the team :)
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 23 Mar 2011 00:44:24 +0000
> From: Harry Van Haaren <harryhaaren@email-addr-hidden>
> Subject: [LAD] MIDI maps : C++ functions
> To: Linux Audio Developers <linux-audio-dev@email-addr-hidden>
> Message-ID:
> <AANLkTimae2N_4LBRC-Zh_1qisTrPOByv+QRfGepwFW5B@email-addr-hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hey guys,
>
> I'm wondering how to approach creating a MIDI map to all controllers
> available in the GUI. Needless to say I can hard code in a MIDI CC, and
> from
> JACK's process callback call the function that I want to map that control
> to, but that's a little rigid.
>
> I like Ardour's one-click map idea, and I'm wondering how its implemented.
> Here's what I concluded so far:
> On mouse_3 down, pop up dialog, send message to JACK process to keep next
> MIDI input stored somewhere. That's the CC to map
>
> Where I'm getting stuck is how to make each CC point to a different
> "parameter" in the software, or a different function in the code. Function
> pointers come to mind, but somehow I don't like that idea much. Creating a
> generic interface to map every control in the entire engine might work,
> but
> I think that may be a little overkill?
>
> I'd be interested to hear how various projects handles this internally, if
> anybody wants to chip in?
> Cheers, -Harry
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxaudio.org/pipermail/linux-audio-
> dev/attachments/20110323/54befb37/attachment-0001.htm>
>
> ------------------------------
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
> End of Linux-audio-dev Digest, Vol 49, Issue 16
> ***********************************************

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Mar 24 04:15:02 2011