Hey all,
I've been pondering lately about loading sessions with Linux Audio, and
realized that
I would find it particularly useful if I could load an LMMS project file
into Ardour, and then
proceed to move that into QTractor, and do my last mastering in Audacity.
As things stand, this is possible, but it requires exporting .wav files,
importing them to Ardour, then
positioning them, doing what you need to do, and proceed to export them
again to move them to another program.
I'm hoping to get opinions if dev's think it may be a good idea to try and
standardize a common "file-type" or "project file"
across Linux Audio Apps.
Eg: Programs support a filetype which is known as a .lap
(LinuxAudioProject..?), and would contain all the MIDI clips,
.wav files, synth settings etc etc across the project. (even JACK output
settings?)
Open to opinions... -Harry
Hi everyone,
a Jackbeat user is currently trying to use TouchOSC, an iPhone app, as a
controller, and there is a need to translate in/out OSC messages.
I have looked at TouchOSC messages, and the translation is nothing like
straightforward. There is a so-called BeatMachine[1] controller in TouchOSC,
which looks like a drum machine, but in the messages that it sends:
1. the track order is reversed, the first track being at the bootom
2. the indexes are one-based in TouchOSC, and zero-based in Jackbeat
3. the track/beat position is transmitted as a path element instead of a value
The fact that some translation is needed between OSC units is quite normal to
me, but I would like to try and follow some wide-spread practices, if any, maybe
refactoring the Jackbeat OSC dialect, to make such translation easier.
I originally looked at some Monome messages docs[2], and that's the reason for
2. and 3. above. The point 1. seems absolutely odd to me however.
Now, there's another thing: currently Jackbeat features quite a few OSC
methods/commands but little OSC events[3]. This forbids using search an external
controller as some kind of UI replacement. For instance, volume sliders can be
controlled, but no event is sent when they change. One of the reason for this
lack is that I was unsure about the right protocol to choose..
So, in TouchOSC, input and output messages seem to always be symmetrical, which
looks like a clever and intuitive design to me. For instance, a slider both
sends and receives messages at /1/fader1 (example). And you just can't setup a
different prefix for in and out.
Once again, this isn't the way Monome is doing it: it sends /40h/press, and
receives at /40h/led.
So I'm a bit confused. What would be ideal is to follow some kind of practices
and/or standard, so that, in many cases, translation is only a matter of
changing OSC prefixes. And if that's not realistic, then I would like to avoid
some of the inconsistencies listed above with tools as TouchOSC and such.
Is there any such standard or common/recommended practices?
Cheers,
[1] http://hexler.net/pub/touchosc/touchosc-manual-v1-1.pdf
[2] http://docs.monome.org/doku.php?id=tech:protocol:osc
[3] http://jackbeat.samalyse.org/wiki/BasicUsage#OSCInterface
--
Olivier
Hi,
The MiniComputer softsynth has problems building on many distros when
fltk-1.x is installed alongside fltk2, and/or the #include directories
don't match where MiniComputer expects them to be and so the build fails
at the configuration stage.
In an effort to fix this quite long standing problem, I've adapted the
SConstruct to use fltk-config and pkg-config to solve these problems.
If you have problems building MiniComputer replace the SConstruct that
comes with MiniComputer with the following file (obviously rename it to
SConstruct first):
http://jwm-art.net/art/text/MiniComputer_SConstruct
It works for me on Gentoo (using accept keyword ~amd64).
I posted here because:
1) I saw similar questions without answers on the list in the past.
2) I've spent several hours getting this to work so people might benefit
from it.
3) I'm a python/scons newbie and hope that those of you with better
knowledge can check it for problems (I've only got this to work by using
Google, trial, and error).
Cheers,
James.
Hi all,
I just finished up my port of Autotalent (A real-time pitch manipulation
program by Tom Baran) to an LV2 plugin (Okay, It's not finished, but all the
important features are there.)
It should work basically the same as Autotalent except:
- It is an LV2 plugin instead of an LADSPA plugin
- It provides MIDI output of the pitch
- It accepts MIDI input
- It separates the pull to semitone and snap to scale functionality
- It uses FFTW for the DFT routines, greatly improving performance.
- Minor performance tweaks (substituting memcpy for loops, etc)
- It is greatly refactored (broken into methods and structures, variables
renamed)
- Does not include smooth pitch jumping or LFO functionality in the first
release (will add later)
- The formant corrector causes artifacts not present in the original (I'm
not sure how to fix, as it's the only part of the original I don't
understand)
I think especially significant is the midi input and output. This would
allow you to do the following:
- Record an audio track in your favorite DAW while running it through the
plugin, and outputting the MIDI to another track
- Correct the midi however you want (keep it monophonic)
- Feed the corrected MIDI track back into the plugin with the recorded
audio, and listen as it corrects the pitch to match the MIDI you gave!
There are also other options, such as controlling an MIDI synth with your
voice, or getting a vocoder-like effect by controlling your voice with a
MIDI keyboard.
You can check out the project page for more information
here<http://code.google.com/p/autotalentlv2/> or
if you want a direct source download, see
here<http://autotalentlv2.googlecode.com/files/autotalent_source.tar.gz>
.
Any feedback on the source code or plugin would be welcome.
Jeremy Salwen
Greetings,
Every now and then I decide to update a page on the original Linux
soundapps site. Recently I cleaned up this page for audio/MIDI plugins :
http://linux-sound.org/plugins.html
Please advise if I've left out anything or if any information there is
wrong. I've covered plugins in LADSPA, DSSI, MESS, LV2, and VST formats,
hopefully I got all the major projects, and I'd like to know if I've
missed anything. TIA!
Best,
dp
Hello all,
This week I had to perform measurements on a audio
interface, and this resulted in some quite interesting
results. Before revealing what happened, I'll let you
have a look at some of the data and come up with your
own conclusions, see
<http://www.kokkinizita.net/linuxaudio/quiz.html>
(Free beer at the next LAC for the best analysis)
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Johannes Kroll wrote:
> In the native Linux VST section, you might want
> to add Wolpertinger, a little subtractive synth in development, open
> source: http://tumbetoene.tuxfamily.org/index.php?category=1
>
Done. :)
> Another excellent Linux native VST host is Renoise: www.renoise.com.
> Non-free though, demo available, the full version costs 58 euros.
>
>
I've added it to the list of compliant hosts.
Thanks !
dp
Hello all,
This has stirred up more interest (also off-list) than
I ever imagined it would !
OK, beers will go to (in no particular order)
Niels: his comments on ADC/DAC reference voltages
provide the key to understanding what happened.
Veronica: for the most to-the-point one-liner.
Florian: (off list) who got it right in the end.
I guess that at least initially all of you put the
blame of card X - either it's crap or it's defective.
But the real culprit is card A, even if it did show
quite well in the loopback test. And what happens is
100 Hz (rectified power grid 50 Hz) ripple on the DAC
and ADC reference voltages, both derived from the same
source.
Most audio ADCs and DACs have two reference voltages
(or one, and then the second is derived internally).
In many cases these are the voltages that correspond
to the min and max PCM values, and even if that is not
the case the conversion factor of the ADC or DAC depends
linearly on these voltages. If they are not well filtered,
any fluctuations do generate AM, and the effects of the
same eror on a ADC and DAC will cancel out.
Cancellation also occurs if the sample clock (if shared by
ADC and DAC) is modulated, but here the effect is delay
modulation, which for a single tone translates into phase
modulation proportional to the frequency of the signal.
Since in this case the sideband levels do not depend on
the measurement frequency, the sidebands are not the
result of clock jitter.
So Veronica is quite right: you can't trust a loopback test.
And if, as in this case, the variations are the result of
mains hum, you can't even trust a setup of two cards using
the same mains power (although exact cancellation as in this
case would be rare).
It is also true that you have to be very careful when using
a low-fi card to test a much better one. In this case the
only purpose of the USB card was to provide a calibrated
analog level, which is required for e.g. EIN measurement.
The card is portable so I can easily take it to the lab and
calibrate it against a high precision certified RMS meter
which I can't take out without first filling out a hundred
forms and then waiting two weeks.
Meanwhile I did measure the signal quality of card X using
a *decent* generator - it is extremely good.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Hi,
I'm trying to find a simple host for my LV2 plugin that allows both midi in
and out, and also allows you to control plugin parameters.
I've found lv2_jack_host, which allows my port configuration, but doesn't
seem to allow you to change the parameters, and I've found lv2rack and
zynjacku, which allow you to change plugin controls, but don't seem to allow
nonstandard input/output port configurations.
Any suggestions would be nice.
Thank you
Jeremy
Hi linux-audio peoples,
I want to announce my new and fun and useful python script -- I call it
'jackctl' -- it basically is a frontend to the jack tools 'jack_lsp' and
'jack_connect'. It's like 'qjackctl' , but since it's command line, no 'q'
!!!
get it here:
http://www.akjmusic.com/software/jackctl20100526.py
Why would I embark on writing such a script? Who would want to use this?
You'll want to try this if one or any of the the following apply:
1) You don't want to have to install the entire QT toolkit for a single
program.
2) If you like the command line, use a console, but still use jack often
enough
3) You've used jack and 'jack_connect' through the command line before, but
hated having to type the full name of the jack ports.
4) You've noticed that 'qjackctl' introduces CPU overhead and xruns you
don't have when you use command-line jack, i.e. you are obsessed with the
lowest possible latency
5) You want a fast, simple interface to connect jack ports that is even
faster than a GUI---no need to point the mouse, just type two numbers and
go!
It's very simple. All you need is Python (and who doesn't have that on their
machine). You put the script in your PATH, or link it/rename it, making sure
it's exectuable. When you run it, you'll see a list of current numbered jack
ports, and you can connect them by typing two numbers separated by a space.
You can disconnect them by typing 'd' then the two numbers separated by a
space. No hassles, and a nice feature is that it will protect you from
making ear-blasting feedback connections. It's even quicker than qjackctl,
b/c it takes more time to point your mouse at the ports in the GUI and then
click 'connect' than it does to type two single-digit numbers and then hit
return, yes?
Let me know how you like it...I'm interested in reasonable feature requests.
One potential TODO would be to make this script have a user-friendly way to
start the jack daemon, but for now, I do that manually....
Enjoy, comments welcome!
--
Aaron Krister Johnson
http://www.akjmusic.comhttp://www.untwelve.org