1 Mar
2012
1 Mar
'12
7:39 p.m.
Howdy,
There's no victory over anything whatsoever. Read it again, it's just a
codename. If that serves anything at all, to my own defense that is,
Qtractor is still a pet project hobby of mine, as all things in Linux
audio world for that matter.
There's been too many saying and comparing Ardour vs. Qtractor. I'm
seeing if often said in too many sentences lately and, believe me, I
cannot stand comfortable with that saying no more.
So here it goes: Ardour is a full fledged, pro-level DAW and, for crying
out loud on its own, the flagship of the free/open-source pro-audio
fleet and movement, not only Linux anymore nowadays. On the other hand,
Qtractor is 'a sequencer' (hinted by its own subtitle, in case you
didn't notice) with a twist and a few of a DAW features. And it strictly
runs on the Linux platform only and most important yet, it has been
targeted to a (re)creational personal home-studio audience ever since.
Heard about the 'techno-boy bedroom' (with a guitar) folk? Well, that's
exactly what it is, from day zero. Hope you all get the picture ;)
Enough whining.
Qtractor 0.5.4 (echo victor) is out and is shouting out loud!
Release highlights:
* Panic command button (NEW)
* Improved audio/MIDI file resource management (NEW)
* MIDI SysEx for instrument plugins (NEW)
* MIDI Controller auto-hook option (NEW)
* MIDI Tools resize ramp (NEW)
* Revised plugin search directory paths (FIX)
* MIDI zero-duration note-on/off queueing (FIX)
* Audio linked-clips looping (FIX)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.5.4.tar.gz
- source package (openSUSE 12.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.sr…
- binary packages (openSUSE 12.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.i5…
http://downloads.sourceforge.net/qtractor/qtractor-0.5.4-3.rncbc.suse121.x8…
- long time ago, far far away: user manual:
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
Change-log:
- Direct access plugin/insert parameter changing tool-tip added.
- A Transport/Panic action enters the scene, in a nostalgic attempt to
emulate the all-MIDI-track-shut-off command of those drop-dead and
primordial MIDI sequencers of all time. Now finally a keyboard shortcut
and mouse click-away ;)
- MIDI editor command redo/undo adjustment now effective on all other
channel events besides notes, which overlap at the same event time.
- A new File/Unlink menu action is now made available from the MIDI clip
editor (aka. piano-roll) for detaching the current linked/ref-counted
MIDI clip into a new auto-incremented SMF filename.
- Some audio/MIDI content/media-file resource management is entering the
scene, taking care of some file-system house-keeping, this gets evident
on unsaved/dead recorded files being automaticaly removed from the
file-system, on session close.
- Killed the old and entirely deprecated LV2 Save/Restore and Persist
feature/extensions support.
- Auto-monitored MIDI events are now merged/queued correctly into the
instrument plugin playback queue, avoiding sudden crashes, hopefully.
- Awesome patch from Albert Graef, thanks, which makes most MIDI SysEx
to get through MIDI instrument plugins at last; applies to DSSI and LV2
plugins only.
- LV2 URID map/unmap feature support added.
- Plugin parameter value redo/undo command aliasing fix.
- Double-clicking in plugin list item now show/activates the plugin's
editor window (was toggling visibility/activation).
- Plugin path settings have been fixed again, with special regards to an
effective LV2_PATH environment variable settlement.
- Session properties dialog now asks to create a new session directory
if the given one does not currently exist.
- MIDI note names and their respective octave numbers are now compliant
with the ISO standard where middle C (60) is now C4 (was C3).
- Fixed audible glitch/pop at the beginning of an audio clip with long
quadratic or cubic shaped fade-in (reported by Lougi Verona, thanks).
- MIDI Controller Auto-Hook patch by Alessandro Preziosi, thanks.
- Make sure all MIDI note-off are always queued after their respective
note-on events when buffering for MIDI input of instrument plugins,
event though for zero duration MIDI note events (hopefully fixing the
hanging notes bug #3476124, as reported by Albert Graef, thanks).
- LV2 MIDI-fx plugin support has been repaired.
- Single-track clip selection logic corrected again, fixing multi-clip
selection drag/move across an odd number of distinct tracks (after a bug
report by Louigi Verona, on linux-audio-dev, thanks).
- MMC Locate time-code hour bit-field fix; MMC Locate now also on loop
turnarounds (patches by Albert Graef, thanks).
- Looping across multiple linked/ref-counted audio clips was incredibly
broken with complete out-of-sync playback. Hopefully fixed now, with
auto-unlinking/cloning all the affected audio clip buffers.
- Audio clip overlapping detection off-by-one(-frame) fix.
- MIDI Tools/Resize value ramp mode has been added (mocking the 'resize
to range' feature request #3467894, by Daniel MacDonald aka. danboid).
Enjoy && Have fun!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
2 Mar
2 Mar
6:41 p.m.
On 03/01/2012 07:40 PM, Rui Nuno Capela wrote:
So here it goes: Ardour is a full fledged, pro-level
DAW and, for crying
out loud on its own, the flagship of the free/open-source pro-audio
fleet and movement, not only Linux anymore nowadays.
It goes without saying that Ardour offers an abundance of features, but
Qtractor's MIDI support is very good, its audio support is more than
just adequate, and its big plus is that it's so easy to learn and use.
Also, despite the "alpha" sticker that you keep putting on it, it's been
working very well for me. In any case, we can be happy that we have both. :)
Now what's still needed is full-fledged OSC support. I mean not just
automation, but real OSC tracks with full recording, playback and
editing capabilities a la MIDI. We've briefly discussed this on the
Qtractor mailing list, and I think that I've read somewhere that Ardour3
has been designed with that in mind as well. But are there any concrete
plans to add an OSC track type to Ardour? That would be a killer
feature, at least for me.
* Panic command button (NEW)
Can you read my mind? :) I was about to ask for this, and now you've
already implemented it! Nice.
One thing I've been wondering about... Could you please elaborate on
what exactly the --enable-lv2-state-files configure option is for? That
was marked as experimental in previous svn revisions, and is one of the
very few options which are disabled by default.
Rui, thanks for all your hard work, and see you @ CCRMA!
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
7:10 p.m.
Hey guys!
I would have to respectfully disagree with Rui as to "amateurishness" of
his sequencer. Having less features or being geared towards specific
workflow or being more specialized rather than all in one hardly makes a
tool a "home studio" tool.
As for people comparing it to Ardour, I would say this is an inevitable
thing ;) In my view both sequencers are important and both have their own
place in the Linux Audio world.
--
Louigi Verona
http://www.louigiverona.ru/
7:17 p.m.
On 03/02/2012 05:41 PM, Albert Graef wrote:
One thing I've been wondering about... Could you please elaborate on
what exactly the --enable-lv2-state-files configure option is for? That
was marked as experimental in previous svn revisions, and is one of the
very few options which are disabled by default.
it is disabled like so because current implementation is fubar on qtractor
a not so short answer: the lv2-state-files extension feature it's all
about making lv2 plugin full state serialized through session data files
and folders, porbably making it all portable across machines and stuff.
ardour might work this way (all session media adata is under a session
directory), but qtractor doesn't (all media files are links to anywhere
on your file-system, until you the user say he/she wants to store them
later in a .qtz zip/archive, being that an option, not the norm)
as things are atm. if you turn it on at configure time, the lv2-state
extension won't live to its prospect from qtractor pov. :)
to my knowledge, linuxsampler-lv2 is the only one which supports all
that, provided you source it from the bleeding-edgy svn trunk.
and now for the fun part: drobilla might ask sooner or later to fubarize
all that xD scnr.
Rui, thanks for all your hard work, and see you @
CCRMA!
it's me who should thank
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
9:10 p.m.
On 03/02/2012 07:17 PM, Rui Nuno Capela wrote:
it is disabled like so because current implementation
is fubar on qtractor
Ok, so I'll just leave it disabled. Thanks for clarifying this.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
3 Mar
3 Mar
6:43 a.m.
On Fri, 2012-03-02 at 18:17 +0000, Rui Nuno Capela wrote:
On 03/02/2012 05:41 PM, Albert Graef wrote:
Well, sort of. The file features are to support plugins that save state
with files. The "how" part is up to the host, you would need that
functionality either way.
As for qtractor's implementation, the next version of Lilv will have a
state API baked in, so (presumably) it will just move to that.
-dr
One thing I've been wondering about... Could you please elaborate on
what exactly the --enable-lv2-state-files configure option is for? That
was marked as experimental in previous svn revisions, and is one of the
very few options which are disabled by default.
it is disabled like so because current implementation is fubar on qtractor
a not so short answer: the lv2-state-files extension feature it's all
about making lv2 plugin full state serialized through session data files
and folders, porbably making it all portable across machines and stuff.
ardour might work this way (all session media adata is under a session
directory), but qtractor doesn't (all media files are links to anywhere
on your file-system, until you the user say he/she wants to store them
later in a .qtz zip/archive, being that an option, not the norm)
6:50 a.m.
On Fri, 2012-03-02 at 18:41 +0100, Albert Graef wrote:
On 03/01/2012 07:40 PM, Rui Nuno Capela wrote:
Not really, though it wouldn't be all that hard if Jack had a generic
event API like it should. Unfortunately it doesn't so there's that
roadblock in the way[1].
There is also the chicken & egg problem, last I checked there wasn't an
OSC note standard in use anywhere to have Ardour send...
-dr
[1] Though logistically the implementation couldn't care less what kind
of bytes are in a message; basically the function names are just stupid.
We'll probably end up sending non-MIDI stuff around with jack_midi_*
functions, or copy/pasting the entire API. Lovely.
So here it goes: Ardour is a full fledged,
pro-level DAW and, for crying
out loud on its own, the flagship of the free/open-source pro-audio
fleet and movement, not only Linux anymore nowadays.
It goes without saying that Ardour offers an abundance of features, but
Qtractor's MIDI support is very good, its audio support is more than
just adequate, and its big plus is that it's so easy to learn and use.
Also, despite the "alpha" sticker that you keep putting on it, it's been
working very well for me. In any case, we can be happy that we have both. :)
Now what's still needed is full-fledged OSC support. I mean not just
automation, but real OSC tracks with full recording, playback and
editing capabilities a la MIDI. We've briefly discussed this on the
Qtractor mailing list, and I think that I've read somewhere that Ardour3
has been designed with that in mind as well. But are there any concrete
plans to add an OSC track type to Ardour? That would be a killer
feature, at least for me.
7:36 a.m.
On 03/03/2012 06:50 AM, David Robillard wrote:
There is also the chicken& egg problem, last I
checked there wasn't an
OSC note standard in use anywhere to have Ardour send...
I don't see why an OSC track should make any assumptions about the
semantics of OSC messages. It should just treat it as control data and
allow to record it from an OSC client (which might also be an LV2 plugin
which produces OSC messages), edit it, and play it back to another OSC
server (or LV2 plugin which consumes OSC messages).
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
9:53 a.m.
On 03/03/2012 07:36 AM, Albert Graef wrote:
I don't see why an OSC track should make any assumptions about the
semantics of OSC messages.
For optimized representation and editing.
Avoiding artificial restrictions can give you both freedom and clumsiness ;)
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
8:25 p.m.
On Sat, 2012-03-03 at 07:36 +0100, Albert Graef wrote:
On 03/03/2012 06:50 AM, David Robillard wrote:
Hm? How would a sequencer display or edit OSC data without even knowing
how to represent a note or a control?
Sure, you could just implement dumb raw OSC recording and playback, but
there's little point in using a DAW for that (not to mention little
practical musical use)
-dr
There is also the chicken& egg problem, last
I checked there wasn't an
OSC note standard in use anywhere to have Ardour send...
I don't see why an OSC track should make any assumptions about the
semantics of OSC messages. It should just treat it as control data and
allow to record it from an OSC client (which might also be an LV2 plugin
which produces OSC messages), edit it, and play it back to another OSC
server (or LV2 plugin which consumes OSC messages).
11:20 p.m.
On 03/03/2012 08:25 PM, David Robillard wrote:
Sure, you could just implement dumb raw OSC recording
and playback, but
there's little point in using a DAW for that (not to mention little
practical musical use)
But that's exactly what I want. For starters, even just simple messages
consisting of address and POD (like a double value) would be useful. The
data might originally be generated with a multitouch OSC device, say,
and would be recorded by the DAW, which would also let me play back the
data, sending it either to an OSC-capable plugin or an external OSC
application (Pd, say) which would know what to do with it. Call it
automation, if you want. But I think of it as sequencing of OSC
messages; I need the data to be on its own track where I can edit, cut,
copy and move it around as needed. DAW and sequencer programs are good
at these things; that's what they are for. And no, I don't want to use
MIDI instead, where I have to cram everything into control changes or
(N)RPNS and loose both resolution and the descriptive OSC addresses.
I don't know if it's of practical use for anyone else, but time and
again I would have had good use for this apparently simple feature. If
anyone knows a sequencer or DAW which can do what I sketched out above,
please do tell me. OSC has been around since 1997, for crying out loud.
It's about time that sequencers do more with it than just automatizing
the transport controls. ;-)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
11:29 p.m.
On Sat, Mar 3, 2012 at 5:20 PM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
On 03/03/2012 08:25 PM, David Robillard wrote:
this general language is the whole problem.
you can't send OSC to "an OSC capable plugin" or "an external OSC
application" in any generalized sense, because there is no shared
format for the messages.
the sequence of messages that you record may make sense to Pure Data,
but make absolutely no sense to, say, CSound.
the motivation to develop the infrastructure for recording, playback,
disk storage and editing of such messages is not very strong when any
given sequence can only target one particular OSC receiver. the
motivation isn't zero, to be clear. but it just isn't that strong.
Sure, you could just implement dumb raw OSC recording and playback, but
there's little point in using a DAW for that (not to mention little
practical musical use)
But that's exactly what I want. For starters, even just simple messages
consisting of address and POD (like a double value) would be useful. The
data might originally be generated with a multitouch OSC device, say, and
would be recorded by the DAW, which would also let me play back the data,
sending it either to an OSC-capable plugin or an external OSC application I don't know if it's of practical use for
anyone else, but time and again I
would have had good use for this apparently simple feature. If anyone knows
a sequencer or DAW which can do what I sketched out above, please do tell
me. OSC has been around since 1997, for crying out loud. It's about time
that sequencers do more with it than just automatizing the transport
controls. ;-)
then its about time that people using OSC start defining some
standardized messages. MIDI did this from the start, and for all of
its limitations, its been a wild success. the OSC community has
self-consciously avoided doing this - lets queue up another pointless
argument about how to represent notes/frequencies/intervals - and as a
result is still only a niche protocol with every transmitter and
receiver defining their own messages. double fail ...
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
4 Mar
4 Mar
12:55 a.m.
On 03/03/2012 11:29 PM, Paul Davis wrote:
you can't send OSC to "an OSC capable
plugin" or "an external OSC
application" in any generalized sense, because there is no shared
format for the messages.
Yes, there is. It's the OSC format itself. If you want to keep it
simple, you could boil it down to "atomic" OSC messages (i.e., POD
payload, no bundles). If you can support that in a DAW, I'm sure that
there will be plenty of applications which can make good use of this.
(Actually just simple pairs of OSC addresses and double values would be
good enough for a lot of stuff IMHO.)
then its about time that people using OSC start
defining some
standardized messages.
Well, what you see as a problem, I see as a virtue. It gives me the
flexibility to just pick my own set of messages for the application at
hand. The sequencer shouldn't have to care about the particular set of
OSC addresses I'm using.
MIDI did this from the start, and for all of
its limitations, its been a wild success.
Nobody argues that, certainly not me. For much stuff we do, MIDI is
quite adequate. But there's also the more advanced stuff where OSC is
better suited or maybe just more convenient. That's certainly the case
if you're using an OSC device like the Lemur, or if you're building a
dsp plugin with Faust and don't want to go through the tedium of
handpicking MIDI controller assignments.
Anyway, Paul, I understand that you have plenty of other important stuff
on your TODO list for Ardour3. I'm not complaining. The reason that I
brought up Ardour in this context was that I seem to recall reading
something on the Ardour website, about Ardour3 already having the right
infrastructure which would make it easy to add some kind of OSC tracks.
Maybe I've misread that remark, though.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
3:47 a.m.
On Sun, 2012-03-04 at 00:55 +0100, Albert Graef wrote:
[...]
Anyway, Paul, I understand that you have plenty of
other important stuff
on your TODO list for Ardour3. I'm not complaining. The reason that I
brought up Ardour in this context was that I seem to recall reading
something on the Ardour website, about Ardour3 already having the right
infrastructure which would make it easy to add some kind of OSC tracks.
Maybe I've misread that remark, though.
I probably said this. Internally it's like Jack in most of the
important places, i.e. the actual type of the event payload is pretty
much irrelevant. The biggest problem to solve is the on-disk format.
Control data (i.e. "automation") in Ardour is its own thing, not even
really MIDI related. I co-opted the existing automation system as much
as possible deliberately for this reason. It could be made to *send*
OSC messages for curves pretty easily.
It would be nice if this integrated with stuff in the plugin sphere, but
I've come to the conclusion that, unfortunately, OSC is more trouble
than it's worth there (though nothing is stopping anyone from using it).
After countless attempts at achieving a decent more-powerful-than-MIDI
mechanism, I've come to this opinion:
Give me a simple data model based on primitives, lists, and dictionaries
any day over some clunky command-like message format.
To me, the easy integration that gives you (with e.g. the dictionary
built in to pretty much every programming language ever, Turtle, JSON
(and thus webby everything), key:value stores), the 'meaningfulness', a
standard string serialisation, and an easy ability to describe
arbitrarily complex things via nesting, is of infinitely more value than
integrating with the tiny nichey collection of things that support OSC.
Maybe it's just that I've tried to do some pretty advanced things on top
of OSC (like 100% of GUI<=>engine control), but it's just a little too
half-assed for my tastes these days.
That said, I'm fully behind anything that would provide the individual
note control and high controller precision that MIDI can't.
-dr
2:14 p.m.
On 03/04/2012 03:47 AM, David Robillard wrote:
I probably said this. Internally it's like Jack
in most of the
important places, i.e. the actual type of the event payload is pretty
much irrelevant. The biggest problem to solve is the on-disk format.
That shouldn't be a real problem. OSC is already serialized after all,
and uses network byte order. So you can just take those blobs and save
them to a file and read them back again.
Control data (i.e. "automation") in Ardour
is its own thing, not even
really MIDI related. I co-opted the existing automation system as much
as possible deliberately for this reason. It could be made to *send*
OSC messages for curves pretty easily.
If it can be made to also record OSC messages and if I can pick the OSC
addresses that I want, then this would probably satisfy most of my needs.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
6:32 p.m.
On Sun, 2012-03-04 at 14:14 +0100, Albert Graef wrote:
What do you mean by "pick the OSC addresses that I want"?
-dr
On 03/04/2012 03:47 AM, David Robillard wrote:
I would assume that any realtime local transport via something like Jack
or plugins would eschew the network byte order thing since that's quite
a massive amount of overhead for no reason. You'd have to to actually
send it over a network protocol or disk though, of course.
Sure, given that you already have a POD serialization, inventing such a
format wouldn't be hard. Perhaps just invent a RIFF chunk for them.
Time stamps may be a question for sample accuracy.
I probably said this. Internally it's like
Jack in most of the
important places, i.e. the actual type of the event payload is pretty
much irrelevant. The biggest problem to solve is the on-disk format.
That shouldn't be a real problem. OSC is already serialized after all,
and uses network byte order. So you can just take those blobs and save
them to a file and read them back again. Control data
(i.e. "automation") in Ardour is its own thing, not even
really MIDI related. I co-opted the existing automation system as much
as possible deliberately for this reason. It could be made to *send*
OSC messages for curves pretty easily.
If it can be made to also record OSC messages and if I can pick the OSC
addresses that I want
10:27 p.m.
On 03/04/2012 06:32 PM, David Robillard wrote:
What do you mean by "pick the OSC addresses that
I want"?
I mean those symbols with the slashes that are the first part of any
atomic OSC message like /foo/bar 4711.0. Usually such a symbol would
denote the particular control that the value applies to. When using OSC
as input to or output from automation, obviously I'd have to specify
which OSC addresses I want to be mapped to which automation parameter.
However, I'd actually prefer a kind of separate OSC track which would be
connected to OSC inputs and outputs and listens for all OSC messages on
its OSC inputs, no matter what the addresses are. So (an ASCII
representation of) the contents of such a track might look like
# delta OSC addr value
0 /foo/bar 0.78
10 /reverb1/wet 0.3
5 /foo/bar 0.66
etc. etc.
By these means the OSC track would just record any messages that it
receives on its inputs, and I might then map them to the appropriate
automation parameters on other (audio and MIDI) tracks in the DAW, or
just have them played back via the OSC outputs assigned to the track, in
order to drive some other application like Pd.
Dave, will you be at LAC in April? I'd really like to discuss this in
more detail with you, but it's much easier to do this in a room together
and with a whiteboard and a data projector within reach. ;-) If there's
enough interest, maybe we could do a "control beyond midi" brainstorming
session at LAC? Maybe Rui wants to join us there, and I know that some
guys at CCRMA are also interested in this. I guess that the organizers
can allocate us a time slot and a room with the necessary equipment if
we just ask for it.
Albert
P.S.: Rui, apologies for hitchhiking your thread. I hope that you will
forgive me over a glass of good Californian wine. ;-)
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
10:51 p.m.
On Sun, 2012-03-04 at 22:27 +0100, Albert Graef wrote:
On 03/04/2012 06:32 PM, David Robillard wrote:
Ah.
What do you mean by "pick the OSC addresses
that I want"?
I mean those symbols with the slashes that are the first part of any
atomic OSC message like /foo/bar 4711.0. Usually such a symbol would
denote the particular control that the value applies to. When using OSC
as input to or output from automation, obviously I'd have to specify
which OSC addresses I want to be mapped to which automation parameter. Dave, will you be at LAC in April? I'd really like
to discuss this in
more detail with you, but it's much easier to do this in a room together
and with a whiteboard and a data projector within reach. ;-) If there's
enough interest, maybe we could do a "control beyond midi" brainstorming
session at LAC? Maybe Rui wants to join us there, and I know that some
guys at CCRMA are also interested in this. I guess that the organizers
can allocate us a time slot and a room with the necessary equipment if
we just ask for it.
Indeed it would be a much easier way to bang things out, but
unfortunately I won't be attending this year. Perhaps next...
-dr
11:26 p.m.
On 03/04/2012 09:27 PM, Albert Graef wrote:
P.S.: Rui, apologies for hitchhiking your thread. I hope that you will
forgive me over a glass of good Californian wine. ;-)
no worries. given the length of the thread i think i'll take two please ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
11:47 p.m.
On 03/04/2012 11:26 PM, Rui Nuno Capela wrote:
no worries. given the length of the thread i think
i'll take two please ;)
Ok, granted. I'd even make that two bottles if you implement OSC tracks
in Qtractor. ;-)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
5 Mar
5 Mar
1:40 a.m.
On Mon, Mar 5, 2012 at 7:47 AM, Albert Graef <Dr.Graef(a)t-online.de> wrote:
On 03/04/2012 11:26 PM, Rui Nuno Capela wrote:
I'm chiming in late here, but it is a topic I've thought about a
little having experimented in the domain. Given the open-endedness of
OSC, I've always thought it makes more sense to implement some kind of
plugin based translators, as it were, something like the ladosc ladspa
plugins but with more flexibility and eliminating the need for both a
sender and receiver plugin.
For instance, if one were to implement an LV2 OSC instrument, you
automatically get multi-host compatibility without having to expect
the host dev's to agree on a standard as such. The plugin would simply
need some kind of sensible interface to define namespaces for the
translated midi events that the host would be sending to the plugin
via the standard sequencer interface. This way, discrete and
continuous events could be mapped to OSC output within the UI of the
plugin. I hope I'm making sense.
Alas, this is more than I can do, but if a developer were feeling up
to it I'd be more than happy to line up for testing.
no worries. given the length of the thread i think i'll take two please ;)
Ok, granted. I'd even make that two bottles if you implement OSC tracks in
Qtractor. ;-)
Albert
2:17 a.m.
On Mon, 2012-03-05 at 09:40 +0900, michael noble wrote:
[...]
I'm chiming in late here, but it is a topic
I've thought about a
little having experimented in the domain. Given the open-endedness of
OSC, I've always thought it makes more sense to implement some kind of
plugin based translators, as it were, something like the ladosc ladspa
plugins but with more flexibility and eliminating the need for both a
sender and receiver plugin.
For instance, if one were to implement an LV2 OSC instrument, you
automatically get multi-host compatibility without having to expect
the host dev's to agree on a standard as such. The plugin would simply
need some kind of sensible interface to define namespaces for the
translated midi events that the host would be sending to the plugin
via the standard sequencer interface. This way, discrete and
continuous events could be mapped to OSC output within the UI of the
plugin. I hope I'm making sense.
I don't really grasp what you're getting at here, or what MIDI has to do
with it, etc. However, using plugins to process/filter/whatever OSC
messages is natural (same thing for Jack apps). You can use any event
types in LV2.
What you'd need to work with OSC in plugins is a simple implementation
capable of reading and writing OSC messages in realtime. Liblo is too
heavy for that.
Reading is probably easy. Writing is a bit trickier, I struggled with
inventing a decent API for a similar thing (LV2 atoms, not OSC, but same
idea), but eventually arrived at an "append-based" API which works
pretty well. I call this the "forge" API for atoms. A similar scheme
could work for OSC, e.g hard real-time code to write the message
"/foo/bar if 1 3.0" could look something like:
OSC_Forge forge;
osc_forge_set_output(output_butter, n_bytes);
OSC_Msg msg;
osc_forge_msg_start(&msg, "/foo/bar");
osc_forge_int(1);
osc_forge_float(3.0);
osc_forge_msg_finish(msg)
One unfortunate thing with OSC is the size of the type string must be
known in advance[1], so you might have to pass that to osc_forge_msg.
Nesting (bundles) can be handled automagically, the forge maintains a
stack (without allocating, of course). Such a thing can be implemented
in a single smallish header.
I think a very simple stand-alone API to deal with OSC message would go
a long way towards making OSC more feasible for plugins or Jack apps.
-dr
[1] I consider this a mistake in OSC. The type tag should precede each
argument so messages can be built sequentially by simply appending
successive arguments.
3:27 a.m.
On Mon, Mar 5, 2012 at 10:16 AM, David Robillard <d(a)drobilla.net> wrote:
I don't really grasp what you're getting at here, or what MIDI has to do
with it, etc. However, using plugins to process/filter/whatever OSC
messages is natural (same thing for Jack apps). You can use any event
types in LV2.
That'll teach me for waffling before my morning coffee.
I really meant nothing more than saying that an instrument plugin that
can send OSC could be triggered via a midi sequencer. Of course, that
doesn't do anything about the issue of being able to record OSC, and
in the end, also isn't that much easier than sending midi from the
sequencer to say PD and letting PD do the translating to OSC messages.
-m
12:13 p.m.
On 3/5/12 2:16 AM, David Robillard wrote:
I think a very simple stand-alone API to deal with OSC
message would go
a long way towards making OSC more feasible for plugins or Jack apps.
there are at least two options: a header library i've been using in a
couple of projects [1] and oscpack [2]. both c++ though ...
<sk>
[1] https://github.com/kaoskorobase/oscpp
[2] http://www.rossbencina.com/code/oscpack
9:50 p.m.
On Mon, 2012-03-05 at 12:13 +0100, Stefan Kersten wrote:
On 3/5/12 2:16 AM, David Robillard wrote:
OSCPack uses the stream-style << abuse syntax, arguably (though not
really) the most awful thing about C++.
OSCPP looks pretty good though. Basically a C++ey version of what I was
talking about. Thanks for the pointers.
The "require a size before constructing a message" thing sucks for
certain cases of generic construction, however this might only be really
much of an issue for bundles which don't have that problem, so maybe
it's not such a big deal.
I have been idly wondering if a round-trip OSC<=>Atom bridge would be
possible. Atoms are essentially primitives (int, float, string, etc)
with a few simple collections, all POD (vector, dictionary). You can
think of it as sort of a JSONish approach, but low-level rather than
text.
I wonder how one would express a dictionary in OSC?
Assuming for the moment embracing and extending types is fine, there is
one easy cop-out solution, make a type-tagged-blob type, the same as the
normal one except it starts with a type int, but that's pretty opaque.
Maybe something like [] for arrays? {kvkv...}, e.g.
/foo/adict {sssi} "name" "David" "id" 42
=
{ "name": "David"
"id": 42 }
-dr
I think a very simple stand-alone API to deal
with OSC message would go
a long way towards making OSC more feasible for plugins or Jack apps.
there are at least two options: a header library i've been using in a
couple of projects [1] and oscpack [2]. both c++ though ...
6 Mar
6 Mar
2:07 p.m.
New subject: OSC vs LV2 atoms (was: [ANN] Qtractor 0.5.4 - Echo Victor shouts out!)
On 05.03.12 21:50, David Robillard wrote:
On Mon, 2012-03-05 at 12:13 +0100, Stefan Kersten
wrote:
it's probably an attempt to provide a nicer syntax for packet creation and i
can't say i dislike it - if c++ had first class functions it probably wouldn't
be necessary. anyway, it's only syntax, and as far as i can tell packet creation
and parsing is realtime safe in oscpack.
On 3/5/12 2:16 AM, David Robillard wrote:
OSCPack uses the stream-style << abuse syntax, arguably (though not
really) the most awful thing about C++. I think a very simple stand-alone API to deal
with OSC message would go
a long way towards making OSC more feasible for plugins or Jack apps.
there are at least two options: a header library i've been using in a
couple of projects [1] and oscpack [2]. both c++ though ... OSCPP looks pretty good though. Basically a C++ey
version of what I was
talking about. Thanks for the pointers.
The "require a size before constructing a message" thing sucks for
certain cases of generic construction, however this might only be really
much of an issue for bundles which don't have that problem, so maybe
it's not such a big deal.
I have been idly wondering if a round-trip OSC<=>Atom bridge would be
possible. Atoms are essentially primitives (int, float, string, etc)
with a few simple collections, all POD (vector, dictionary). You can
think of it as sort of a JSONish approach, but low-level rather than
text.
it seems to be rather similar to bson [1] actually.
I wonder how one would express a dictionary in OSC?
Assuming for the moment embracing and extending types is fine, there is
one easy cop-out solution, make a type-tagged-blob type, the same as the
normal one except it starts with a type int, but that's pretty opaque.
Maybe something like [] for arrays? {kvkv...}, e.g.
/foo/adict {sssi} "name" "David" "id" 42
=
{ "name": "David"
"id": 42 }
without the need for new types you could also "abuse" the bundle system, by
interpreting bundles within the top-level bundle as dictionaries with messages
as key/value pairs; this changed semantics would need to be explicitly supported
by other applications, of course.
there's some talk about this in a thread on OSC 2.0 [2], but i couldn't find a
draft document of the new protocol revision.
<sk>
[1] http://en.wikipedia.org/wiki/BSON
[2] http://lists.create.ucsb.edu/pipermail/osc_dev/2011-November/thread.html#19…
9:23 p.m.
New subject: OSC vs LV2 atoms (was: [ANN] Qtractor 0.5.4 - Echo Victor shouts out!)
On Tue, 2012-03-06 at 14:07 +0100, Stefan Kersten wrote:
Interesting. I was unaware of this spec. Yes, very similar, though
Atoms have 64-bit alignment, and more extensibility (we use URID
integers for type rather than a byte).
Atoms also lack a real "dictionary", objects always have URID keys
because that 'meaningfulness' is very useful, and its fast. A
dictionary type with flexible keys could be added...
It would be nice if an existing spec could be used (I looked in to
protocol buffers as well), but none quite fit.
Sounds like maybe "Enables encoding of structured content by using
nested bundles" (from [2]) would facilitate this without have to kludge
the semantics.
On 05.03.12 21:50, David Robillard wrote:
[...]
I have been
idly wondering if a round-trip OSC<=>Atom bridge would be
possible. Atoms are essentially primitives (int, float, string, etc)
with a few simple collections, all POD (vector, dictionary). You can
think of it as sort of a JSONish approach, but low-level rather than
text.
it seems to be rather similar to bson [1] actually. > I wonder how one would express a dictionary in
OSC?
[...]
/foo/adict
{sssi} "name" "David" "id" 42
=
{ "name": "David"
"id": 42 }
without the need for new types you could also "abuse" the bundle system, by
interpreting bundles within the top-level bundle as dictionaries with messages
as key/value pairs; this changed semantics would need to be explicitly supported
by other applications, of course. there's some talk about this in a thread on OSC
2.0 [2], but i couldn't find a
draft document of the new protocol revision.
Interesting. Looks like they have the right goals. I am tempted to
follow this, but the very last thing I need is to be involved in yet
another spec :)
-dr
5 Mar
5 Mar
12:24 p.m.
On Sun, Mar 04, 2012 at 12:55:39AM +0100, Albert Graef wrote:
Well, what you see as a problem, I see as a virtue. It
gives me the
flexibility to just pick my own set of messages for the application at
hand. The sequencer shouldn't have to care about the particular set of
OSC addresses I'm using.
Agreed 100%.
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
1:01 p.m.
Am 5. März 2012 12:24 schrieb Fons Adriaensen <fons(a)linuxaudio.org>rg>:
On Sun, Mar 04, 2012 at 12:55:39AM +0100, Albert Graef
wrote:
Agreed 40%
Having a standard scheeme for _standard procedures
doesn't kill your freedom to still pick custom addresses / add
your own extensions to OSC,
but simplifies things A LOT for those 90% of users who do standard things,
as playing back notes and controlling typical values (e.g. velocity,
volume, resonance...)
Thus you wouldn't lose any virtue, but those 90% woud gain some.
--
E.R.
Well, what you see as a problem, I see as a
virtue. It gives me the
flexibility to just pick my own set of messages for the application at
hand. The sequencer shouldn't have to care about the particular set of
OSC addresses I'm using.
Agreed 100%.
4 Mar
4 Mar
8:14 a.m.
Am 3. März 2012 23:29 schrieb Paul Davis <paul(a)linuxaudiosystems.com>om>:
I totally agree.
Actually OSC missed the point of MIDI.
(Or there was no intention to acctually become a replacement !? )
There should at least be an accepted, standardized
way for transmission of MIDI data over OSC !
I've started a draft:
http://wiki.linuxaudio.org/wiki/user/emrum/midi-osc-map
--
E.R.
OSC
this general language is the whole problem.
you can't send OSC to "an OSC capable plugin" or "an external OSC
application" in any generalized sense, because there is no shared
format for the messages.
the sequence of messages that you record may make sense to Pure Data,
but make absolutely no sense to, say, CSound.
the motivation to develop the infrastructure for recording, playback,
disk storage and editing of such messages is not very strong when any
given sequence can only target one particular OSC receiver. the
motivation isn't zero, to be clear. but it just isn't that strong.
I don't know if it's of practical use for
anyone else, but time and again I
would have had good use for this apparently simple feature. If anyone knows
a sequencer or DAW which can do what I sketched out above, please do tell
me. OSC has been around since 1997, for crying out loud. It's about time
that sequencers do more with it than just automatizing the transport
controls. ;-)
then its about time that people using OSC start defining some
standardized messages. MIDI did this from the start, and for all of
its limitations, its been a wild success. the OSC community has
self-consciously avoided doing this - lets queue up another pointless
argument about how to represent notes/frequencies/intervals - and as a
result is still only a niche protocol with every transmitter and
receiver defining their own messages. double fail ...
11:14 a.m.
On Sat, Mar 3, 2012 at 11:14 PM, Emanuel Rumpf <xbran(a)web.de> wrote:
Am 3. März 2012 23:29 schrieb Paul Davis
<paul(a)linuxaudiosystems.com>om>:
I totally agree.
Actually OSC missed the point of MIDI.
(Or there was no intention to acctually become a replacement !? )
There should at least be an accepted, standardized
way for transmission of MIDI data over OSC !
I've started a draft:
http://wiki.linuxaudio.org/wiki/user/emrum/midi-osc-map
Yes, OSC is useless as it comes out of the box. So is TCP. So is
access to audio hardware. It's a transport mechanism. Look to
libmapper for a way to make it generally useful. I've implemented
something similar for useful OSC signaling in Non-*, but it's
conceptually the same as libmapper and (currently imaginary) JACK OSC
ports. Generic Input and output signals which can be connected to one
another without requiring each party to be separately configured. And,
for the record, liblo defines a MIDI datatype for transport of midi
over OSC--although I don't see much point to doing that, as it merely
combines the deficiencies of both.
OSC
this general language is the whole problem.
you can't send OSC to "an OSC capable plugin" or "an external OSC
application" in any generalized sense, because there is no shared
format for the messages.
the sequence of messages that you record may make sense to Pure Data,
but make absolutely no sense to, say, CSound.
the motivation to develop the infrastructure for recording, playback,
disk storage and editing of such messages is not very strong when any
given sequence can only target one particular OSC receiver. the
motivation isn't zero, to be clear. but it just isn't that strong.
I don't know if it's of practical use for
anyone else, but time and again I
would have had good use for this apparently simple feature. If anyone knows
a sequencer or DAW which can do what I sketched out above, please do tell
me. OSC has been around since 1997, for crying out loud. It's about time
that sequencers do more with it than just automatizing the transport
controls. ;-)
then its about time that people using OSC start defining some
standardized messages. MIDI did this from the start, and for all of
its limitations, its been a wild success. the OSC community has
self-consciously avoided doing this - lets queue up another pointless
argument about how to represent notes/frequencies/intervals - and as a
result is still only a niche protocol with every transmitter and
receiver defining their own messages. double fail ...
11:50 a.m.
Am 4. März 2012 11:14 schrieb J. Liles <malnourite(a)gmail.com>om>:
On Sat, Mar 3, 2012 at 11:14 PM, Emanuel Rumpf
<xbran(a)web.de> wrote:
There should at least be an accepted, standardized
way for transmission of MIDI data over OSC !
I've started a draft:
http://wiki.linuxaudio.org/wiki/user/emrum/midi-osc-map
Yes, OSC is useless as it comes out of the box. So is TCP. So is
access to audio hardware. It's a transport mechanism. Look to
libmapper for a way to make it generally useful. I've implemented
something similar for useful OSC signaling in Non-*, but it's
conceptually the same as libmapper and (currently imaginary) JACK OSC
ports. Generic Input and output signals which can be connected to one
another without requiring each party to be separately configured. And,
for the record, liblo defines a MIDI datatype for transport of midi
over OSC--although I don't see much point to doing that, as it merely combines the deficiencies of both.
True somehow.
OTOH if most applications would have a
_standardized_ mechanism to support musical control over OSC,
there would be a small chance, that OSC could replace MIDI
somewhere in the future.
The chance for MIDI to improve seems very low, due to its technical limits.
IRC Yamaha as an improved MIDI format for their digital pianos,
but I wouldn't call that a standard.
--
E.R.
1:05 p.m.
On Sun, Mar 4, 2012 at 2:50 AM, Emanuel Rumpf <xbran(a)web.de> wrote:
Am 4. März 2012 11:14 schrieb J. Liles
<malnourite(a)gmail.com>om>:
I personally don't think that the way notes are encoded is the primary
limitation imposed by MIDI. A note is a frequency, an attack/decay
modulation, and a duration. MIDI does an acceptable job of handling
these. If you want more resolution, then the ultimate is a waveform...
The way OSC is used, and in libmapper in particular, is to say things
about the input device, not the music, which, as far as the input
device is concerned, doesn't exist. Things like the low-resolution
continuous variation of force applied to a button, or the position of
a finger on the length of a resistive strip. These things have nothing
to do with music, so the fact that there's no standard for notes is
not a problem. The standard I propose (and use), as does libmapper, is
that of Control Voltage floating point values between 0.0 and 1.0.
Generally speaking, the neither the source nor the sink cares about
the scale of the value, only that it varies between a minimum and a
maximum. Users like to see the actual values, but it is a much more
usable system if they are scaled to 0.0-1.0 on the wire.
On Sat, Mar 3, 2012 at 11:14 PM, Emanuel Rumpf
<xbran(a)web.de> wrote:
There should at least be an accepted, standardized
way for transmission of MIDI data over OSC !
I've started a draft:
http://wiki.linuxaudio.org/wiki/user/emrum/midi-osc-map
Yes, OSC is useless as it comes out of the box. So is TCP. So is
access to audio hardware. It's a transport mechanism. Look to
libmapper for a way to make it generally useful. I've implemented
something similar for useful OSC signaling in Non-*, but it's
conceptually the same as libmapper and (currently imaginary) JACK OSC
ports. Generic Input and output signals which can be connected to one
another without requiring each party to be separately configured. And,
for the record, liblo defines a MIDI datatype for transport of midi
over OSC--although I don't see much point to doing that, as it merely combines the deficiencies of both.
True somehow.
OTOH if most applications would have a
_standardized_ mechanism to support musical control over OSC,
there would be a small chance, that OSC could replace MIDI
somewhere in the future.
The chance for MIDI to improve seems very low, due to its technical limits.
IRC Yamaha as an improved MIDI format for their digital pianos,
but I wouldn't call that a standard.
2:38 p.m.
On 3/4/12, J. Liles <malnourite(a)gmail.com> wrote:
I personally don't think that the way notes are
encoded is the primary
limitation imposed by MIDI. A note is a frequency, an attack/decay
modulation, and a duration.
apparently you're forgetting or have not been a part of the many
debates with the music technology community about how to define "a
note". personally i'm happy with what you wrote, but i know several
people who have made cogent arguments that defining notes in terms of
frequencies completely misses one of the most musical semantics.
The way OSC is used, and in libmapper in particular,
is to say things
about the input device, not the music, which, as far as the input
device is concerned, doesn't exist.
as as receiver of OSC, i'd be entirely happy with such a standard. the
problem for users is that it leaves the mappings unspecified, and
although there are some clever solutions for this (several of them),
from a user's perspective it always adds an extra layer of complexity.
contrast with MIDI, where almost all the messages that most people
will generate have a defined meaning even from the sender's
perspective (though sure, the receiver can still map it to something
else if it wants to).
6:05 p.m.
Am 4. März 2012 14:38 schrieb Paul Davis <paul(a)linuxaudiosystems.com>om>:
... the
problem for users is that it leaves the mappings unspecified, and
although there are some clever solutions for this (several of them),
from a user's perspective it always adds an extra layer of complexity.
contrast with MIDI, where almost all the messages that most people
will generate have a defined meaning even from the sender's
perspective (though sure, the receiver can still map it to something
else if it wants to).
Exactly.
Once upon the time, GM was helpful.
If you made your sequencer play a BassDrum, on one synth,
it would play a BassDrum on a different GM machine too,
without any configuration.
Today MIDI + GM appear too limited.
We need 3 drum-kits, 10 snares, 52 channels, 64 bit
.... spoiled musicians ;)
With current OSC, one would have to configure the headstrong soup of both
sender and receiver.
--
E.R.
6:48 p.m.
On Sun, 2012-03-04 at 08:38 -0500, Paul Davis wrote:
The thing is, reality has turned MIDI in practice to everything being
learn-based (except notes) anyway. Most of the crap in MIDI can just go
away, since the use case is "send a whatever with a number(s) in it
somewhere the receiver can pick up on".
There are a few things that need to be standardized, like notes and
transport control, but I think everything having a universal meaning is
at best dubious, and likely a mistake. It is inevitable that you need
learn and/or controller mappings anyway, so the protocol can be a simple
description of what's happening on the *sender*. What the receiver does
with it is its own business.
This is a pretty controller-centric opinion, but I don't think OSC is
really good for much beyond that anyway, and the only cases that it
might be (controlling Pd and such) the (power) user is designing their
own messages anyway so it's a non-issue.
-dr
On 3/4/12, J. Liles <malnourite(a)gmail.com>
wrote:
To me, one of the primary limitations about MIDI is the lack of ability
to control individual notes. For example, a good protocol could let you
start at C, slide up to A, do some vibrato, etc., e.g. you could draw
lines in your sequencer.
Identifying the note by frequency would preclude this. Note numbers are
better.
I personally don't think that the way notes
are encoded is the primary
limitation imposed by MIDI. A note is a frequency, an attack/decay
modulation, and a duration.
apparently you're forgetting or have not been a part of the many
debates with the music technology community about how to define "a
note". personally i'm happy with what you wrote, but i know several
people who have made cogent arguments that defining notes in terms of
frequencies completely misses one of the most musical semantics. The way OSC is
used, and in libmapper in particular, is to say things
about the input device, not the music, which, as far as the input
device is concerned, doesn't exist.
as as receiver of OSC, i'd be entirely happy with such a standard. the
problem for users is that it leaves the mappings unspecified, and
although there are some clever solutions for this (several of them),
from a user's perspective it always adds an extra layer of complexity.
contrast with MIDI, where almost all the messages that most people
will generate have a defined meaning even from the sender's
perspective (though sure, the receiver can still map it to something
else if it wants to).
8:38 p.m.
Guys, can you explain to me, who is not very well aware of OSC
and MIDI debates, why not come up with at least a Linux Audio OSC
standard for notes and just use that?
--
Louigi Verona
http://www.louigiverona.ru/
10:30 p.m.
On Sun, 2012-03-04 at 22:38 +0300, Louigi Verona wrote:
Guys, can you explain to me, who is not very well
aware of OSC
and MIDI debates, why not come up with at least a Linux Audio OSC
standard for notes and just use that?
Chicken & Egg problem.
(Never trust a spec not actually used by anyone)
-dr
5 Mar
5 Mar
12:23 p.m.
On Sat, Mar 03, 2012 at 05:29:14PM -0500, Paul Davis wrote:
this general language is the whole problem.
you can't send OSC to "an OSC capable plugin" or "an external OSC
application" in any generalized sense, because there is no shared
format for the messages.
the sequence of messages that you record may make sense to Pure Data,
but make absolutely no sense to, say, CSound.
So what ? When a user needs a 'sequencer' or whatever you may call it,
for OSC messages that means he/she already has a source and destination
that understand each other. It's completely irrelevant if others understand
the same messages.
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
3 Mar
3 Mar
11:36 p.m.
On 03/03/2012 11:20 PM, Albert Graef wrote:
On 03/03/2012 08:25 PM, David Robillard wrote:
Hi Albert,
I use Algoscore for sequencing OSC.
http://kymatica.com/Software/AlgoScore
There was a presentation at Piksel a few years back about this one:
https://github.com/sentinelweb/TimeLine-OSC
and http://www.iannix.org/ may do the job as well.
..but neither aims for, or comes close to "DAW" functionality.
robin
Sure, you could just implement dumb raw OSC
recording and playback, but
there's little point in using a DAW for that (not to mention little
practical musical use)
But that's exactly what I want. For starters, even just simple messages
consisting of address and POD (like a double value) would be useful. The
data might originally be generated with a multitouch OSC device, say,
and would be recorded by the DAW, which would also let me play back the
data, sending it either to an OSC-capable plugin or an external OSC
application (Pd, say) which would know what to do with it. Call it
automation, if you want. But I think of it as sequencing of OSC
messages; I need the data to be on its own track where I can edit, cut,
copy and move it around as needed. DAW and sequencer programs are good
at these things; that's what they are for. And no, I don't want to use
MIDI instead, where I have to cram everything into control changes or
(N)RPNS and loose both resolution and the descriptive OSC addresses.
I don't know if it's of practical use for anyone else, but time and
again I would have had good use for this apparently simple feature. If
anyone knows a sequencer or DAW which can do what I sketched out above,
please do tell me. OSC has been around since 1997, for crying out loud.
It's about time that sequencers do more with it than just automatizing
the transport controls. ;-)
Albert
4 Mar
4 Mar
1:10 a.m.
On 03/03/2012 11:36 PM, Robin Gareus wrote:
I use Algoscore for sequencing OSC.
http://kymatica.com/Software/AlgoScore
Hi Robin,
thanks for the pointers. Yes I know about AlgoScore and Iannix, but
that's not quite what I had in mind.
There was a presentation at Piksel a few years back
about this one:
https://github.com/sentinelweb/TimeLine-OSC
Interesting, I don't remember seeing this. Unfortunately, the original
website is down and the video on vimeo has lousy sound, but I'll have to
see whether I can get this up and running.
..but neither aims for, or comes close to
"DAW" functionality.
Alas. Maybe I'm a bit old-fashioned, but for recording and playing back
stuff on a timeline, nothing beats a DAW-like interface for me. :)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
3:31 a.m.
On Sat, 2012-03-03 at 23:20 +0100, Albert Graef wrote:
On 03/03/2012 08:25 PM, David Robillard wrote:
I suppose this would be useful in some limited sense.
However, I doubt Ardour ever will, nor do I think it even should,
support sequencing of events that are transmitted by some mechanism
other than Jack. That would be a gigantic inconsistent mess for more
reasons than I feel like listing, and trying to use UDP or whatever
directly in a DAW raises a very large number of very deep questions for
no benefit (hell, anti-benefit, Jack rules). Integration with IP based
OSC transport should happen via a separate Jack program.
Put in other terms, I think Ardour should support "OSC Messages". Not
OSC in UDP/TCP/IP. If the community solves Jack OSC, it will get Ardour
OSC pretty quickly. However, I am kind of through with OSC personally,
so I don't intend to put any real effort into the Jack side of that
problem.
Sure, you could just implement dumb raw OSC
recording and playback, but
there's little point in using a DAW for that (not to mention little
practical musical use)
But that's exactly what I want. For starters, even just simple messages
consisting of address and POD (like a double value) would be useful. The
data might originally be generated with a multitouch OSC device, say,
and would be recorded by the DAW, which would also let me play back the
data OSC has been around since 1997, for crying out loud.
It's about time that sequencers do more with it than just automatizing
the transport controls. ;-)
As Paul pointed out in his response, the reason for this lack is that
OSC simply doesn't do what 99.999999999999% of the people who use a
sequencer want to do. Blindly recording events with no editing or
display ability simply isn't that useful, and certainly doesn't
constitute a MIDI replacement.
That said, it's not like a note standard would actually be difficult.
It will (well, may) get actually made when someone actually needs it.
Since we live in a somewhat closed and more flexible world, the Jack
universe could be the place where that happens. I doubt it will
elsewhere, the commercial guys have gone with custom incompatible USB
protocols for hardware, and simply don't care about software interop.
-dr
1:56 p.m.
On 03/04/2012 03:31 AM, David Robillard wrote:
However, I doubt Ardour ever will, nor do I think it
even should,
support sequencing of events that are transmitted by some mechanism
other than Jack. That would be a gigantic inconsistent mess for more
reasons than I feel like listing, and trying to use UDP or whatever
directly in a DAW raises a very large number of very deep questions for
no benefit (hell, anti-benefit, Jack rules). Integration with IP based
OSC transport should happen via a separate Jack program.
That makes perfect sense to me.
As Paul pointed out in his response, the reason for
this lack is that
OSC simply doesn't do what 99.999999999999% of the people who use a
sequencer want to do.
99.999999999999% of the world population is zero, I guess that's me,
thanks. ;-) That's your take on what users want, I disagree. Add OSC
tracks to Ardour and people will find good uses for it, that's my take.
Blindly recording events with no editing or
display ability simply isn't that useful, and certainly doesn't
constitute a MIDI replacement.
Why should it be recorded blindly? It's not rocket science to come up
with a convenient interface to edit and visually represent something
like generic OSC data. In fact, Ardour automation would almost fit the
bill if there was a way to record and play the data from/to external
devices and applications in a way which doesn't take the MIDI detour.
You can argue that OSC is too limited all day, but in any case it's
better than 7 bit values with 7 bit addresses. I'd be more than happy to
use any other semi-standard format which offers this and has at least
some support in applications. But what we have right now for
transferring control data is MIDI and OSC. If you know about anything
else please do tell me. I can't drive a Pd patch with a data format that
doesn't exist. I can get control data from OSC devices and feed that to
Pd, however. Just bad luck that none of the major DAWs supports it
directly, so I have to fit my square OSC peg into the round MIDI hole to
make that work. ;-)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
5 Mar
5 Mar
12:19 p.m.
On Sat, Mar 03, 2012 at 11:20:00PM +0100, Albert Graef wrote:
I don't know if it's of practical use for
anyone else, but time and
again I would have had good use for this apparently simple feature.
Same here. It would have immensely simplified some past projects,
and some more the come.
There are many forms such a tool could take. It could be completely
unaware of the 'meaning' of any messages, and just reproduce them at
the right time. It could be made aware of some simple but recurring
formats such as /foo/bar ,ff X Y and display them in a way that makes
sense. It could even be made to store some data (e.g. continuous
control values, or even 'notes' in an internal format and output them
in and OSC format defined by the user.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
11:33 a.m.
On Thu, Mar 1, 2012 at 10:40 PM, Rui Nuno Capela wrote:
- Direct access plugin/insert parameter changing
tool-tip added.
I'm not sure it makes a terrible sense to post this to LAD rather than
to LAU, but I'd just like to notice that I'm not extremely happy with
the current implementation of direct access for the following reasons:
1. Only one setting per plug-in is available, so I can't have control
over, say, attack and release in a compressor simultaneously.
2. The widget is hard to aim (which is probably a trade-off with an
aim to make UI compact). Maybe some phat-like slider would do the
trick?
3. The step for mouse wheel scrolling is too large by default and
doesn't change to a more granular one with Alt/Shift modifier buttons.
Re widgets, here is another idea:
http://www.darktable.org/2012/03/bauhaus-widgets/
I'm not totally sure about it yet, I've yet to compile that branch.
But just so you know... :)
Alexandre Prokoudine
http://libregraphicsworld.org
5:42 p.m.
On 03/05/2012 10:33 AM, Alexandre Prokoudine wrote:
On Thu, Mar 1, 2012 at 10:40 PM, Rui Nuno Capela
wrote:
the so called "direct access feature" does only affect one and only one
plugin parameter at a time, that being an implementation/design
limitation due to the fact that the provided slider widget is scalar and
1-dimensional by nature o.O
to tweak more than one parameter simultaneously, for what i'm curious on
how you actually could do just that with one 1-dimensional slider, i'll
assume you're asking for simultaneous access over the same display
space, then look at the generic plugin dialog (plugin/properties) or the
plugin own gui editor (plugin/edit), if any.
- Direct access plugin/insert parameter changing
tool-tip added.
I'm not sure it makes a terrible sense to post this to LAD rather than
to LAU, but I'd just like to notice that I'm not extremely happy with
the current implementation of direct access for the following reasons:
1. Only one setting per plug-in is available, so I can't have control
over, say, attack and release in a compressor simultaneously. 2. The widget is hard to aim (which is probably a
trade-off with an
aim to make UI compact). Maybe some phat-like slider would do the
trick
true. however i have no interesting plan on that regard. maybe, if
someone steps up with a patch or sth... ;)
3. The step for mouse wheel scrolling is too large by
default and
doesn't change to a more granular one with Alt/Shift modifier buttons.
true and the good news are it can be fixed sooner perhaps ;)
Re widgets, here is another idea:
http://www.darktable.org/2012/03/bauhaus-widgets/
I'm not totally sure about it yet, I've yet to compile that branch.
But just so you know... :)
too bad it looks like it's gtk2. i'm sure someone could rip it off as a
qt4 widget and drop it in without much brain-sweat, someone with a lot a
time to spare? ;)
don't take me wrong. i love the ideas
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
5:48 p.m.
On Mon, Mar 5, 2012 at 8:43 PM, Rui Nuno Capela wrote:
to tweak more than one parameter simultaneously, for
what i'm curious on how
you actually could do just that with one 1-dimensional slider
What would I want that for? Just provide one slider per setting :)
Works like a charm in A3 :)
Deliberate limitation is a whole different thing, of course.
Alexandre Prokoudine
http://libregraphicsworld.org
5:59 p.m.
On 03/05/2012 04:48 PM, Alexandre Prokoudine wrote:
On Mon, Mar 5, 2012 at 8:43 PM, Rui Nuno Capela
wrote:
you have that in the generic plugin dialog or eventually on the its own
provided gui editor. i'm sure that's exactly the same in a3.
otoh, i don't think a3 has this "direct access thingie", so which
limitation is what? :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
to tweak more than one parameter simultaneously,
for what i'm curious on how
you actually could do just that with one 1-dimensional slider
What would I want that for? Just provide one slider per setting :)
Works like a charm in A3 :)
6:15 p.m.
On Mon, Mar 5, 2012 at 8:59 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
On 03/05/2012 04:48 PM, Alexandre Prokoudine wrote:
http://i.minus.com/iiLod2lQiZ5nx.png
Alexandre Prokoudine
http://libregraphicsworld.org
On Mon, Mar 5, 2012 at 8:43 PM, Rui Nuno Capela wrote:
you have that in the generic plugin dialog or eventually on the its own
provided gui editor. i'm sure that's exactly the same in a3.
otoh, i don't think a3 has this "direct access thingie" to tweak more than one parameter simultaneously,
for what i'm curious on
how
you actually could do just that with one 1-dimensional slider
What would I want that for? Just provide one slider per setting :)
Works like a charm in A3 :)
6:26 p.m.
On 03/05/2012 05:15 PM, Alexandre Prokoudine wrote:
On Mon, Mar 5, 2012 at 8:59 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
awesome that's a definite plus to (flagship) a3 i guess :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 03/05/2012 04:48 PM, Alexandre Prokoudine
wrote:
http://i.minus.com/iiLod2lQiZ5nx.png
On Mon, Mar 5, 2012 at 8:43 PM, Rui Nuno Capela wrote:
you have that in the generic plugin dialog or eventually on the its own
provided gui editor. i'm sure that's exactly the same in a3.
otoh, i don't think a3 has this "direct access thingie" to tweak more than one parameter simultaneously,
for what i'm curious on
how
you actually could do just that with one 1-dimensional slider
What would I want that for? Just provide one slider per setting :)
Works like a charm in A3 :)
4640
days inactive
4645
days old
linux-audio-dev@lists.linuxaudio.org
49 comments
13 participants
participants (13)
-
Albert Graef -
Alexandre Prokoudine -
David Robillard -
Emanuel Rumpf -
Fons Adriaensen -
J. Liles -
Louigi Verona -
michael noble -
Paul Davis -
Robin Gareus -
Rui Nuno Capela -
Stefan Kersten -
Thorsten Wilms