[ardour-dev] jack/ardour application extension(s)

[Robin Gareus]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Davis wrote:
> On Tue, 2007-02-20 at 18:40 +0100, Robin Gareus wrote:
> 
>> Why on ardour-dev ?
>>
>> I'd like to get the current zoom-range from ardour (either query or
>> notify) - AFAIR ardour's menu can be customized, too (hook to change
>> video-file path of xjadeo or gjvidtimeline). - is there doc around for
>> that?
> 
> pretty difficult to figure that out, but we could add it to OSC. i don't
> think we've done any OSC query support yet, but i think that liblo makes
> it pretty easy to support. what do you want to do with the zoom range?
> 

want to use it as range for gjacktransport and gjvidtimeline.

Limiting gjvideotimeline's frame-count to //one// descends into
gtk-RGB-xjadeo! Future versions of xjadeo might be able to *toggle*
between single frame and [multi-row?] time-line preview.. I might not be
the only one to find it useful to change xjadeo (or other apps)
behaviour via ardour-bindings.

at some point I was thinking that gjvtl can be used to directly render
into the ardour-timeline, but that will just bring up many detail issues
that gjvt is just not ready for [yet?]. - anyway with an "always on top"
- - and syced zoom-range it's just as good as!

OTOH, while using gjvt during the last days, I had the impression that
it makes more sense to stick to a fixed zoom level, and allow to define
'video-frame' markers: render/show only preview images for specific sync
points in a linear timeline.

Thus the next question - same caliber: can I access ardour's
location-markers (other than parsing the session's XML file)? - and  can
I reposition ardour's edit cursor?


>> where to start best? - Is it welcome to "integrate" external software
>> into ardour like this? -
> 
> very welcome, except that we need to "evolve" some good generic
> mechanisms for it.
> 

gjvt it's not that high-up in my ToDo list as it might seem, but I'll
gladly contribute if no one else does...

i dare say you agree that it should become a bi-directional interface.
IMO LASH support is on the way to implement an ardour remote-control!

OSC seems straight forward. - a first version could hardcode
OSC-callback handlers (query or notify) into ardour. - the "evolved"
version would use a dlopen(3) plugin system (like good old xmms1)
bridging ext.remote-control-commands to an ardor-internal
remote-control-API (i'd guess the internal LASH or MIDI API work quite
similar)

Will it make sense to have a realtime-remote, someday?? that could be
done via JACK (audio-callback ext-info) or custom POSIX-mqueue's.

to round it up there should be a nice GUI-frontend to
add/download/disable extensions - while an extension can display
ardour-(buttons, automation-tracks: RGB-buffers or value+timestamp
pairs, menu-items,..)? ...but that sounds rather like a feature for
ardour > 3.0 - or will be solved by other desktop toolkit integration
endeavors down the road.

nice generic evolveable interfaces are really cool as long as they make
the common case fast! - I guess that a quick'n'dirty hack would work in
less than 3 hours with ardour2, while discussing a remote-ctl API could
take weeks.. - something in between would be nice: lay a few head-corner
stones. any suggestions? nudges in the right direction?

sorry for yet another lengthy reply - maybe it's a bad time to bring up
these issues at the current stage of ardour2-dev. last thing I wanna do
is to urge anyone into post-2.0 issues. - unless there's few things that
can be fixed easily (smart scheduling), I'll switch context to different
projects and wait for the next interrupt #:-p

so long,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF3yixeVUk8U+VK0IRAosoAKCc1Geh6/g/joYrICEEaNscret+BACeNxC6
Yb4gVwn1Ye0u5x36z66XVAg=
=HNgh
-----END PGP SIGNATURE-----