On Wednesday 14 November 2007, Phil Frost wrote: [...] Maybe... I considered Control as well, but to me, both of those sound more like single instances of something (just like Ports), rather than the Class/Type style (ie "Voice Pitch Controls") term I'm looking for. *Some* plugin API or something somewhere must have something similar to this, I'd think, but I can't remember seeing one... //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

Phil Frost wrote: Attribute? (not to be confused with Buzz attribute, which is something totally different) Property? (both OO-lovers and OO-haters would perhaps hate me for it) Setting? Control/controller? (it might even reuse CC messages in case we use something similar to my fixed-size 8-byte MIDI Port record passing scheme - or control port numbers and extended record, just some ports would be flagged as "permits 2D addressing", you know what I mean?) Control sink? (that's just bad, too COM/DirectShow/GStreamer-like) Multifunction aftertouch? (that's bad as well, but I'm hoping to seed some ideas here) Articulation? I still don't think we know enough about different ways of doing per-note addressing, by the way, how the parameter numbers are presented to the host, if they should be the same parameters than normal ones or different, per-note parameters... Or how the "final" MIDI port spec should look like, either. <threadjack> And I think it should be decided on rather sooner than later, because otherwise Lars' first proposal (http://ll-plugins.nongnu.org/lv2/ext/MidiPort/) will become the de-facto standard - and while it's definitely a good start, some very simple improvements have been already proposed: - aligning records to 4 bytes (so that we don't have unexpected crashes on SPARC machines etc) - using 16:16 fixed point values instead of doubles (I've proposed an int, but 16:16 looks better) - float-typed control port value changes, to replace or supplement the outdated NRPNs - there are at least two flavours possible; the first one is adding extension record consisting of 32-bit int for parameter number and 32-bit float for parameter value, the second one is by reusing ctl1 and ctl2 or cmd and ctl1 of the basic event for LSB and MSB of 16-bit control port number, and adding an extension record consisting of 32-bit float. In fact I can think of a third one - giving both new float value and the per-sample increment, so that a linear change of a parameter over time can be communicated to a plugin. So we'd have: struct MIDIRecord { uint16_t timestamp_samples; uint16_t timestamp_fract; union { struct { uint8_t cmd, ctl1; // use when flags&1 == 0 }; struct { uint16_t param_num; // use when flags&1 == 1 }; }; uint8_t ctl2; // reserved when flags&1 uint8_t flags; // bit 0 set iff float extension record follows, bits 4-7 contain the second part of the "2D address" tuple }; // this follows the MIDIRecord is expected when flags & 1 struct MIDIRecordExtFloat { float new_value; float new_delta; // typically 0 unless we have a very smart host that does parameter smoothing :) }; Any unsolved problems and counterproposals? - and, maybe in the same spec, maybe in a "sibling" extension, the per-note control ports/2D addressing we're talking about now (I've included my 2D addressing solution in the proposal above, but I have no idea if this particular approach is OK for anyone else than me :) ). </threadjack> Krzysztof

On Thursday 15 November 2007, Dave Phillips wrote: Yes, that's how I made the Win32 binaries for Kobo Deluxe, DT-42 etc. Some libraries (depending on build tools, mostly) may need some "help" to install in the cross-compiler environment, but widely used cross platform libs (SDL, GTK+ etc) usually cross-compile out of the box and/or come with pre-built packages for cross-compiling. Before considering building a cross compiler of your own (which is not terribly hard these days, but still), check what's available for cross-compiling on your distro! The Linux->Win32 case is a rather popular one, but some distros have cross compiler packages for other target platforms as well. [...] That should work too, but doesn't seem to make much sense if you're already running the "home" platform of the GNU tools. :-) Cygwin is probably the easiest way to get started with that, whether you're using Wine or Windows: http://www.cygwin.com/ //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'