On Fri, Aug 23, 2013 at 12:48:22PM +0100, Chris Goddard wrote:
> Hi Adrian
Hi!
Let me CC Robin and LAD on this one.
> Hope you don't mind me contacting you directly, but I have a
> question regarding the RME TCO option and how it is supposed to
> work. I saw your name on some ALSA commits relating to the TCO
> recently and thought you would at least be the right person to start
> by asking.
>
> The TCO can read ltc, but once it has done that how does it
> communicate that time information tothe user space ? If I was, say,
> running Ardour and wanted it to chase this ltc what would Ardour
> need to do to make use of it ?
To be honest: I don't know, I've only fixed the kernel side of it. ;)
There are 1.5 ways to read the TCO's LTC output from userspace:
1. Via ioctl. Needs currently unreleased alsa-lib containing my
commit 4b169b05b48f4ea0196879b62b8c3fa5b050e806 and newest driver,
Takashi's sound-2.6 is fine.
Then, use SNDRV_HDSPM_IOCTL_GET_LTC. To the best of my knowledge,
that's the proper way to read the LTC and it's what I've fixed.
2. If the TCO is present, we create a MIDI output port sending the
MTC. At least I think it's MTC. Since the data is directly
generated by the TCO, the driver has no influence on it. No idea
if it helps in your case if you set this port as the MTC input
port in Ardour.
So it looks like for proper LTC support, we either need some converter
(maybe there already is one?) or ardour needs to be augmented. I have
absolutely no idea what the preferred approach is, but I'm sure Robin or
Paul do.
Maybe it's easiest to add another input path to one of Robin's LTC libs
that just runs the appropriate ioctl and parses the output. Since the
LTC is already decoded by the TCO, it should be pretty straight-forward.
Oh, and last not least: I don't own a TCO, so I cannot really test
anything. Fortunately, the ioctl is purely software, so a mockup should
do the trick.
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
Hey All,
I've written up a blog post on allocating (audio) buffers in real-time.
The trigger was designing the record functionality for Luppp.
http://openavproductions.com/realtime-buffer-allocation
Hope its of interest to some, -Harry
CAPS Audio Plugin Suite 0.9.12
http://quitte.de/dsp/caps.html
New in this release:
Eq4p, a four-way parametric equaliser
http://quitte.de/dsp/caps.html#Eq4p
(Unlike Fons', this one uses parallel processing but lacks control
smoothening other than that provided by a continuous IIR filter
history.)
Elsewhere, a few stupid bugs have been fixed (one of them keeping
PhaserII from reaching strong effect levels), the documentation has
undergone a major revision, many plugins have been polished, some
renamed, and lots of unnecessary ones have been removed.
http://quitte.de/dsp/caps.html#Download
Enjoy!
Anybody from Europe, who still has got EPROMS used by some old
equipment?
It seems to be, that the EPROMS I burned in the stone age, without
protecting them against UV light, are still 100% ok nowadays.
I'm really surprised.
It's not completely off-topic for those who sometimes care about
dino-synth under European sunlight, when the RAMs where replaced by
EPROMS.
I'm positively surprised :).
Really, I'm stunned in a positive way :).
[Julien Claassen]
> I have been recording music for 11 years now, with Linux. [...]
> I'm not sure, if my luck is due to the commandline, it tends to eliminate
> a lot of problems, or if I'm just lucky with my Linux. :-)
I think the small applications with narrow focus you find used on the
commandline are simply a good match for the Linux audio ecosystem with
its many one-man part-time projects.
On the other hand there's a strong desire among users and developers
for applications with a rich feature set and often also a pretty
graphical interface. It can of course be done, even by just one man,
but it takes a lot of time, vast depth and breadth of skill and
dedication and a stable list of features for both the project itself
and the libraries involved to make such applications *and polish them
to professional standards*.
I watch this ambition not without sympathy, but also not without
occasionally speculating what the Linux audio landscape might look
like with less lofty and more UNIX-shaped goals.
Tim
CAPS 0.9.10
===========
http://quitte.de/dsp/caps.html
The CAPS Audio Plugin Suite, a LADSPA library comprising classic sound
effects, various signal generators and guitar tone processing, sees
another update containing some bug fixes, minor sound improvements in
various places and a new plugin, "Spice", which, strangely, appears
not to be an exciter.
http://quitte.de/dsp/caps.html#Spice
In addition, the package documentation has been revised and some
errors corrected.
http://quitte.de/dsp/caps.html#Download
Enjoy!
Hi all
This weekend i got a message from the dev of Hypercyclic and Tonespace that
a new version of these apps is available and they includes jack support
You can find info about the arpeggiator and the softsynth here :
http://www.mucoder.net/en/
If you are interested in beta testing, you can contact the dev via this
page : http://www.kvraudio.com/forum/viewtopic.php?p=5449152
Notes:
- 64 bit only
- these apps are crossplatform, free, but not open source (however, the
dev is putting effort into linux support so that's gottta count for
something, right ?)
- i'm not involved in any way in this project, so it's best to contact the
dev directly if you have any questions (you can find his details here :
http://www.mucoder.net/en/about/)
grtz
Thijs
I write this with some caution, as i have no wish to start another
lengthy discussion on the merits of various session managers.
I'm using non-session-manager to manage my projects, and i will say here
it's been successful and time-efficient, to put it mildly. As a user
with a lot to startup, nsm has enabled me a lot more time to write, and
spend less time on non-writing tasks. (no pun intended)
I know this discussion has been had before, but can i ask devs to take
another look at nsm-patching their apps, if not already done?
The following would be particularly appreciated, here at alextone.
Muse2
(This one is a biggie, as i pretty well write nearly all midi)
a2jmidid
(The default is no -e switch. I don't know why this is, as it seems to
be that a2jmidid -e is more likely to be used by default, than not. If
this is not nsm-patchable, can we at least have a build option that
creates an additional bin exec, something like "a2jmidid-all", or
"a2jmidid-e"?)
linuxsampler
(I start this one from a script that includes the init-after-exec
switch, with a default template. Is LS nsm-patchable to "save" a
particular .lscp, so it can be started automatically with a session?
i.e. Session one uses "orchestra.lscp, session 2 uses "jazz-combo.lscp,
and so on)
Jconvolver
(Same as above. Can jconv be nsm-patched, so i can use different
IR.confs for different sessions, and a specific .conf can be saved with
a session ?)
Thanks,
Alex.
Hi everybody
We are very happy to announce the MOD Pitch Shifter
https://github.com/portalmod/mod-pitchshifter.git
After some unsuccessfull time looking for a nice pitch shifter to offer in
the MOD Cloud we decided to make one ourselves. Kudos for Andre Coutinho
who did most of the coding.
We tried VocProc and Rubberband but none gave satisfactory results, the
first being too complicated and the latter yelding too much latency.
It is very simple to use - a simple semitones shift and a quality lever -
and sounds pretty nice.
The team is working on it to make it even nicer but this first version
sounds pretty good already.
It uses the fftw3 lib which is pretty common and can be installed via the
main linux repositories (ubuntu, debian, arch, etc)
Hope you all enjoy
Kind Regards
Gianfranco
The MOD Team
