>> All of MIDI can be reduced to two messages: set-control (addressed by
>> Channel, Voice and Controller ID) .. and SYSEX - for data-dumps.
>What you say is of course a true statement, but it is ignoring what the
>founding fathers of MIDI attempted to accomplish regarding efficiency on
>a bandwith limited connection and the likelyhood of certain messages
>appearing more often than others ,,,
Hi Jens,
Very true. MIDI was an excellent solution at the time and made good use of
limited bandwidth.
But I think as MIDI got extended it got too complicated, and now with
software music systems we don't have such limited bandwith anymore. The
8-bit messages are looking dated as far as simplicity and especially
resolution goes.
The MMA are addressing the resolution aspect with "High definition MIDI",
but it's implemented as SYSEX messages and therefore just adds more
complexity to writing a comprehensive MIDI implementation.
I hope in future we'll have a simplified system...instead of CCs and RPNs
and NRPNs and SYSEX Controllers, have a single unified controller with a
32-bit Controller-Number range. Map all the existing MIDI messages into
that range.
NEW-MIDI would have only one message type, it would look like..
[Timestamp][Channel][Voice Number][Controller-Number][Value]
Anyway, I got way off-topic. My intention was to say that LV2 may not need a
per-note control extension because MIDI already has it via "Key Based
Instrument Controllers", which is a SYSEX message for sending a CC to one
specific note-number.
Best Regards,
Jeff
> However, it (MIDI) also has its own age. And limitations. In particular,
the
> amount of per-note control is pitiful.
> .... In the meantime, maybe the MIDI guys will decide for us :D
They did, "Key Based Instrument Controllers" provide for per-note
controllers.
Granted MIDI remains stupid. MIDI is 15 different ways of saying "set this
control".
All of MIDI can be reduced to two messages: set-control (addressed by
Channel, Voice and Controller ID) .. and SYSEX - for data-dumps.
Jeff McClintock
Message: 13
Date: Fri, 30 Nov 2007 00:30:58 +0000
From: Krzysztof Foltman <wdev(a)foltman.com>
Subject: Re: [LAD] "enhanced event port" LV2 extension proposal
To: Dave Robillard <drobilla(a)connect.carleton.ca>, LAD
<linux-audio-dev(a)lists.linuxaudio.org>
Message-ID: <474F59C2.1050805(a)foltman.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Dave Robillard wrote:
> I /really/ don't like screwing around with MIDI. Just make the events
> pure, raw MIDI. Jack MIDI events are 'just n bytes of MIDI', Alsa has
> functions to get at 'just n bytes of MIDI', and... well, it's just MIDI.
>
However, it also has its own age. And limitations. In particular, the
amount of per-note control is pitiful.
I can always use hacks to get around the limitations, or introduce a
per-note control via separate "set note parameter" event type. But hacks
are ... hacky, and the extended extension of extension for every single
feature is a bit inelegant too.
Anyway - so far, I have no code that would make use of this, so we might
keep it as plain MIDI. And then we have next 5 years to decide the
details of the feature. In the meantime, maybe the MIDI guys will decide
for us :D
Krzysztof
Dear all,
the deadline for the call for papers and music for the Linux Audio
Conference 2008 (LAC2008) has been extended.
The new and final deadline for paper and music submissions is now
Thursday, December 6, 2007, 24:00 UTC
(This is equal to Friday, December 7, 2007, 0:00 UTC)
We invite submissions of papers addressing all areas of audio
processing based on Linux and open source software. Papers can focus
on technical, artistic or scientific issues and can target developers
or users.
We are also looking for music that has been produced completely or
mostly under Linux and/or with open source software from every genre:
compositions, Electronica, Chill-Out, Ambient, etc.
For paper submissions, please use the online form at
http://lac.linuxaudio.org/openconf
For music submissions and further details on both calls, please refer
to the calls below and on the web at
http://lac.linuxaudio.org
We are looking forward to many interesting submissions for the 6th
International Linux Audio Conference 2008 and we hope to see you in
Cologne 2008!
Please feel free to forward this e-mail to anybody who might be
interested.
On behalf of the LAC2008 organisation team,
Frank Barknecht and Martin Rumori
----------
Linux Audio Conference 2008 Cologne, Germany
28.02.-02.03.2008
Call for Papers
===============
http://lac.linuxaudio.org/download/lac2008_callforpapers.txt
We invite submissions of papers addressing all areas of audio
processing based on Linux and open source software. Papers can focus
on technical, artistic or scientific issues and can target developers
or users. This includes (but is not limited to) the following
categories:
* Computer Music
* Music Production
* Instruments
* Drivers and Sound Architecture
* Audio Distributions
* Generic (Usage, Documentation etc.)
The conference is held in English.
Length of a paper is 4-8 pages. Papers have to include an abstract
(50-100 words). The abstract will be published separately on the
conference website once the paper has been accepted. Also, papers
should include up to 5 keywords.
In general talks should take 20-30 minutes followed by 5 minutes
discussion.
Please notify us if you need a special technical setup. The technical
standard setup will be:
* microphone/head set
* projector with XVGA input (resolution 1024x768)
* stereo speaker setup with mini jack input
If you are not able to bring your laptop along with you, please notify
us in advance.
How to submit
--------------
* Do not send papers via email as with the past LAC conferences!
* Instead please use the paper upload form in our conference
management system at:
http://lac.linuxaudio.org/openconf
* File format is PDF, formatted for A4 paper. Make use of the
templates for paper formatting available at:
http://lac.linuxaudio.org/download/lac2008_templates.tar.gz
* Authors of papers selected to be included in the printed
conference proceedings will also have to supply supplemental
material like illustrations needed to layout the printed
proceedings separately.
* Deadline for paper submissions is December 6, 2007, 24:00 UTC
Important Dates
----------------
06 Dec 2007: Paper submission deadline
21 Dec 2007: Notification of acceptance
11 Jan 2008: camera ready version
28 Feb - 2 Mar 2008: Linux Audio Conference in Cologne
----------
Linux Audio Conference 2008 Cologne, Germany
28.02.-02.03.2008
Call for Music
==============
http://lac.linuxaudio.org/download/lac2008_callformusic.txt
The conference will include several concerts. We are looking for music
that has been produced completely or mostly under Linux and/or with
open source software from every genre: compositions, Electronica,
Chill-Out, Ambient, etc.
If you want to participate, either send your composition(s) to this
address:
LAC2008 - Call for Music
Kunsthochschule für Medien
Martin Rumori
Peter-Welter-Platz 2
D-50676 Köln
Germany
or send your submission via email to: lac(a)linuxaudio.org
Please do not attach any media files to email submissions, only
provide a URL to where the piece can be downloaded.
Make use of one of the following media formats:
* Media: Audio-CD, DVD, DVD-R, CD-R, Website download
* File formats: aiff, wav, flac, ogg, mp3
* Samplerate: 44.1 or 48 kHz
* Resolution: 16 or 24 bit
* Number of channels: 1 to 8 channels
* Channel format: multi-channel interleaved, multi-mono
Include the following items with your submission (in English):
* A filled-out and signed printout of the form available here:
http://lac.linuxaudio.org/download/lac2008_musicagreement.pdf
The form can be filled out with a computer and printed out afterwards
for signing.
For the printed program and to be published online and on the
conference CD, in continuous text (no table or list please):
* short commentary on the composition(s) (each ca. 150 words)
* short Curriculum Vitae (ca. 100 words)
Deadline for submissions is December 6, 2007, 24:00 UTC
A jury will select the compositions that will be performed/played.
Besides artistic criteria and technical reasons, these criteria apply
for the selection:
Tape pieces or pieces which are performed by the composers themselves
will generally have more chances to get included. If we get more
pieces than we can include in the program, composers who are attending
the conference are preferred.
Terms and conditions for participation can be found in the form
mentioned above. This form includes among other things:
I will receive no fees whether my composition is played or not. GEMA
fees (in case of performance) will be paid by the organizer. The
material I send to the LAC organisation team will not be returned.
Important Dates
----------------
06 Dec 2007: Music submission deadline
21 Dec 2007: Notification of acceptance
28 Feb - 2 Mar 2008: Linux Audio Conference in Cologne
On Sat, 2007-12-01 at 19:32 +0100, David Olofson wrote:
> On Saturday 01 December 2007, Dave Robillard wrote:
> > On Fri, 2007-11-30 at 11:23 +0100, David Olofson wrote:
> > > On Friday 30 November 2007, Krzysztof Foltman wrote:
> > > [...several points that I totally agree with...]
> > > > If you use integers, perhaps the timestamps should be stored as
> > > > delta values.
> > >
> > > That would seem to add complexity with little gain, though I
> > > haven't really thought hard about that...
> >
> > It does have the significant advantage of eliminating the hard upper
> > bound on the range of time that can be present in a buffer (and with
> > 'null' events, eliminates any such limit entirely, ala SMF). More
> > annoying to work with though..
>
> Yeah; someone has to add the "null" events, and the delta nature of
> it, obviously. You could hide that in event handling
> calls/macros/inlines of course, but still...
Yeah, unless there's some compelling cases where splitting the cycle has
a negative side effect, not worth it.
-DR-
Hi,
I've just done as much as I can to make sure wcnt-1.26 is working. I
would
appreciate if anybody would try compiling on other platforms beside Debian
Etch on i686...
http://www.jwm-art.net/wcnt-1.26-test.tar.bz2
..before I upload it to sf.net, etc.
new features to wcnt-1.26
* uses libsndfile for file I/O - wcnt's first library dependancy :)
* several modules interface with LADSPA plugins from SWH and CAPS plugin
sets
(make sure LADSPA_PATH environment is set :)
glame lowpass and highpass filters,
bode frequency shifter,
plate reverbs (mono input & stereo input versions)
sc1 compressor
fast lookahead limiter
dc offset remover
* orbit module - impliments an orbit fractal which iterates on trigger
input.
hopalong threeply and quadrup orbit types. it also auto-scales the
fractal
output after n test iterations. output_x & output_y.
* adsr_scaler - scales individual sections (ie entire attack decay or
release
sections) of an adsr module.
// please fwd this to LAU if that's a more appropriate list as I'm not
// subscribed there.
Please reply offlist with reports of compilation problems, etc, to:
james att jwm-art dott net
Regards, cheers,
James
On Friday 30 November 2007, Dave Robillard wrote:
> > That's why I'm using a Port as the smallest "connection unit",
> > much like LADSPA ports, so there is no need for an event type
> > field of any kind at all, let alone a URI.
>
> Ports /are/ the smallest "connection unit". But ports can /contain/
> events, and if we want multiple kinds of events in a single port,
> then the events themselves need a type field.
Sounds like there's a fundamental difference there, then. I'm using a
model where a port is nothing more than something that deals with a
value of some sort. There are no channels, voices, different events
or anything "inside" a port - just a value. An output port
can "operate" that value of a compatible input port.
Of course, that "value" could be anything, but I'm not explicitly
supporting that on the API level. If plugins want to use MIDI
messages, they're on their own when it comes to mapping of channels,
CCs etc. That stuff is really beyond the scope of my project, as one
wouldn't be able to configure and control such things normally.
> > The data in the events *could* be MIDI or whatever (the host
> > doesn't even have to understand any of it), but normally, in the
> > case of Audiality 2, it'll be modular synth style ramped control
> > events. That is, one port controls exactly one value - just like
> > in LADSPA, only using timestamped events with ramping info instead
> > of one value per buffer.
>
> The host might not have to (though in practise it usually does), but
> other plugins certainly do. You can't process events if you don't
> even know what they are.
Yes, obviously. I don't quite see what you think I'm trying to say
here. :-)
> > Extensibility is a non-issue on this level.
>
> OK, the event extension doesn't define your ramped control events,
> so you're not allowed to use them, ever, period.
>
> ... looks like extensibility is an issue at this level, eh? ;)
Right, but that's mostly about Audiality 2 anyway. There, if I for
some reason started with control events without ramping, I'd add
another "control events v2" port type. If that type happens to be a
superset of the first one doesn't really matter, as they're still not
compatible.
Where it makes sense, one can provide converters to/from other types,
but to the host (the low level machinery directly dealing with plugin
graphs, that is), those are just ordinary plugins with only one input
port and one output port.
> > What you do if you want
> > more stuff is just grab another URI for a new event based
> > protocol, and you get to start over with a fresh event struct to
> > use in whatever way you like. (In fact, as it is, the host doesn't
> > even have to know you'll be using events. It just provides a LIFO
> > pool of events for any plugins that might need it.)
>
> Sounds like you're thinking too hard.
Nah. I'm just in the middle of another project, and the Audiality 2
code isn't in a state where I could post that without just adding to
the confusion. And, I think we might have a terminology impedance
mismatch. :-)
> "Events" here are just a bunch of bytes in a flat buffer.
Mine are implemented as linked lists of small memory blocks, for
various reasons. (I've had a working implementation for years, so
I'll stick with that for now. Not saying it's the best or most
efficient way of doing it, but I have yet to figure out how to bend
flat buffers around my event routing model - or the other way
around.)
I did "hardwire" fixed point timestamps as those are closely related
to the whole deal with sample frames, buffers etc - but the data area
is indeed just a bunch of raw bytes.
> There is definitely no protocol here. Please, please don't
> say "protocol". That way lies painful digressed conversations,
> trust me.
I'm open to alternative terminology. :-)
What I'm talking about is just the name of "whatever goes on between
connected ports." I don't want the term to be too specific, as it
also covers LADSPA style audio buffers, shared buffers (which can
contain function pointers) and whatever else plugins might use to
communicate.
//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 --'
Hi,
A fresh new release from the FreeBoB project is available. It is only a
maintenance release. It fixes a few bugs which were reported. If you
don't have problems with the your current version of libfreebob, there
is no reason to update to this one.
Available through the SourceForge release system at:
http://sourceforge.net/project/showfiles.php?group_id=117802
Have fun recording!
The FreeBoB Team
PS: Expect FFADO soon...
Hi,
A fresh new release from the FreeBoB project is available. It is only a
maintenance release. It fixes a few bugs which were reported. If you
don't have problems with the your current version of libfreebob, there
is no reason to update to this one.
Have fun recording!
The FreeBoB Team
