Please excuse my "youthful" enthusiasm...
I am having some success with my usb computer keyboard as a midi control
surface.
All things are assignable to any key.
the key events press, release, and repeat can be set separately (or
ignored)
Key presses can control:
- Jack transport:
roll
stop
zero
1 or ten sec forward or back (will make this settable)
I have press do one second and repeat do 10
- midi messages these are all in hex and can include:
channel messages like key, ctl, pgm, etc
sysex up to 20 char in total
I am not sure what the limit is for jack
but any of the control surfaces I have
studied seem to send less.
The reality is that there are lots of control surfaces out there and sw
has to handle what they send.
I do have a question though about ardour control by midi. The Mackie IF
says it sends control messages that are in the form num of ticks up or
down. This means I should be able to have a key send ticks up and another
ticks down, but this doesn't seem to work.
Also, It seems the master rec-enable is not toggle-able. Odd. I have tried
both making a map file and using the learn function. Is there more
documentation for this somewhere? It would not be impossible to toggle
things from inside the controler or take ticks up and down and convert to
127 or 1024 steps. This is not just for ardour but I am wanting to know
what is standard.
--
Len Ovens
www.ovenwerks.net
Hi,
I'm looking for a supplier who can provide a turnkey or white label LOW
COST linux compatible portable audio player. SoC embedded linux device.
10k - 150k units. Some hardware customisations may be required.
Any company that is interested in quoting on this project please contact
me directly to discuss the details.
--
Patrick Shirkey
Boost Hardware Ltd
Hi!
Let me forward you an article that was just posted to the AES67 mailing
list. If you consider to implement AES67 one day, this article gives you
a brief introduction to the clocks involved.
If you're already familiar with PTP (IEEE 1588), there's no use in
reading it, since AES67 of course uses PTP (like Ethernet/AVB).
For a real-world implementation, one can assume that PTP is taken care
of by linuxptp, one of the way too many competing PTP implementations.
To the best of my knowledge, linuxptp is really the way forward, all
other implementations are considered obsolete, at least on mainstream
Linux.
Without further ado, here's the article:
http://www.tvtechnology.com/audio/0098/for-aes-timing-is-everything/271322
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
On Mon, Aug 04, 2014 at 12:18:31PM -0700, Russell Hanaghan wrote:
> I'm curious... This application excites me based on the following theoretical layout:
>
> Budget studio with say at least 1 strong central DAW in a control room. Other satellite
> rooms tht can be linked with Gig Ethernet and smaller (cheaper) platforms in those rooms
> for maybe recording certain instruments (drums might be a bitch even at low latencies)
> an feeding those channels back to the master. Effectively replacing shielded audio cables
> (which run into real money) for a Cat5e or Cat6 cable and gig ports either side. Gig
> switches and cards have become cheap, especially compared to half decent shielded pair
> audio cable.
>
> Is this reasonable as it relates to the application?
I'm not entirely convinced by the cost argument, unless you'd wire
a lot of channels. You still need a PC and soundcard at the other
end.
But if you can live with the extra latency (which can be kept low
in particular if you use dedicated NICs and wiring), yes this
could be a use case.
Another use case for a studio would be to make the studio output(s)
available everywhere in the building - offices, bar, etc.
I originally developed this to be able to record concerts at the
concert hall of the CdM in the studio which is at the other end
of the building and on a different floor. Installing audio cables
or an optical fibre was out of the question, but there is network
wiring everywhere.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Anyone interested in beta-testing this please let me know.
Zita-njbridge
-------------
Command line Jack clients to transmit full quality
multichannel audio over a local IP network, with
adaptive resampling at the receiver.
Main features:
* One-to-one (UDP) or one-to-many (multicast).
* Sender and receiver(s) can each have their own
sample rate and period size.
* Up to 64 channels, 16 or 24 bit or float samples.
* Receiver(s) can select any combination of channels.
* Low latency, optional additional buffering.
* High quality jitter-free resampling.
* Graceful handling of xruns, skipped cycles, lost
packets and freewheeling.
* IP6 fully supported.
* Requires zita-resampler, no other dependencies.
Note that this version is meant for use on a *local*
network. It may work or not on the wider internet if
receiver(s) are configured for additional buffering,
and if you are lucky. The current code will replace
any gaps in the audio stream by silence, and does not
attempt to re-insert packets that arrive out of order.
You will need a fairly recent Jack version, as the
code uses jack_get_cycle_times() and no fallback for
that is provided.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
