Here's another video, this one demonstrating the fact that NSM can
manage a single session with clients spread across multiple machines
(nsmd must be running on each system).
http://youtu.be/xzspJXbEoc0
I forgot to show that when you add a client via the GUI, it asks you
which server to start it on. Otherwise, the behavior is identical to
having a session on a single machine. If you just start up an NSM
capable client on any of the machines participating in the session
(with the appropriate environment variable set), then that client will
join the session as normal.
This distributed session feature is just a natural consequence of the
architecture of NSM and doesn't add any complexity to either the
client or server implementation (just a small amount to the session
manager GUI).
I'm getting pretty close to doing the release, but I still have a lot
of documentation to write and update for the user interface changes.
Enjoy!
Greetings,
I notice that whenever I use any Juce-based native Linux VST plugin - fx
or instrument - in Ardour3 the plugin produces dramatically more xruns
than any LV2 or LADSPA plug. Does anyone else have that problem ? If so,
can anything be done about it, apart from raising my latency settings ?
Thanks,
dp
Sometimes, I wonder why I even bother... First, recordmydesktop didn't
work, so I had to film the screen with a video camera, then ffmpeg2theora
took ages to transcode the video from MJPEG and added some annoying clicks
to the audio track, then the new archive.org uploader didn't work, so I was
stuck with using youtube.com, which refuses to display the video in HD.
Alas, I am to learn again and again that the only way to have things done
right is to do them yourself. On that note, I'd like to introduce to the
wider audience a project that I started shortly after writing this:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2008-May/021084.html
... post to the LAD list back in 2008. Well, I haven't been very active
since then--well, such is life--but in the past couple of weeks I've spent
some time developing the idea and I'd like to demonstrate it in the
following video:
http://www.youtube.com/watch?v=ui-gC_ZMeGM
I'll be pushing my changes in the next week or two along with some other
fixes and enhancements to the Non-* family. Those who have been following
on #lad may have already seen draft versions of the NSM API. The final
draft (version 1.0) will be posted to the LAD list soon also.
Robust audio session management on Linux is now a solved problem. You're
welcome ;-)
Enjoy!
hi everyone!
yesterday, i visited my friends' new studio, to help them shake out some
bugs in the patch and fix a monitor problem. there i came across a
really weird issue with the line outputs on two rme fireface 800s:
we put a test tone out in logic (yeah, they run a mac shop), and i went
to measure the outputs. in addition to really high fluctuations from one
output to the next (with identical digital input signals), i measured
huge differences in voltage on the hot and cold side, such as
hot to ground: 2.00 V
cold to ground: 1.82 V
despite the fluctuations across several channels, this trend was pretty
constant. so i figured, maybe this box has a problem with its negative
voltage rail. they had another ff 800 in there, which we measured for
comparison. same issue.
i figured, maybe apple wrote an oscillator with a dc offset, so we
applied a known-good test tone .wav file. same result.
is my thinking flawed, or are rme really delivering such crappy output
stages on such a pricey box?
my multimeter is not a calibrated one, but it's in the 100+€ range, and
i used AC true rms measurement mode.
i understand my meter has a very high input impedance, and that's what
line level connections should have, right? operating more or less
open-loop, without significant currents flowing. or should i use a shunt
resistor and measure across that? if so, what value is recommended?
thanks for any insights, best,
jörn
Hello all,
I've written a new sampler/drum machine lv2 plugin called DrMr. You can
find it here: https://github.com/nicklan/drmr
It's main reason to exist is to give a way for lv2 hosts to have a built
in drum synth that can save its entire state (i.e. no need to go out to
external tools and no need to save extra state). DrMr currently
supports the following:
- Control via midi
- Scan for and load hydrogen drum kits
- Multi-layer hydrogen kits (will pick layer based on that sample's
set gain)
- Kit is set via an LV2 control
- LV2 controls for gain on each sample
- LV2 controls for pan on each sample
- GTK ui that can select a kit and control gain/pan on each sample
There's more info in the README.md which you can see if you click the
above link. There are a couple of screenshots on the github wiki page.
I hope people find it useful, and as it's rather new code, bug reports
are of course very welcome.
Cheers,
Nick
On Tue, Feb 14, 2012 at 5:49 PM, Nick Lanham wrote:
> Firstly, yes, at some point I would like to have kit editing/creation
> available from the GUI. This is non-trivial however, and a bit down the
> road.
>
> To your second point, I agree that it's non-optimal to have to fire up
> hydrogen to make minor changes to kits and the like. However, I still think
> DrMr improves the situation, as it sits nicely in your host, saves all your
> parameters, and doesn't require any external routing. Of course if you're
> fine with setting up all the external routing and kit loading etc, you
> should just avoid DrMr all together, hydrogen is more fully featured and
> almost certainly more stable anyway, but the whole point of me writing DrMr
> was that I got sick of having to set up both my host and hydrogen for every
> track i wanted to open.
Nooooooo, I actually quite like the idea of being able to JFD drums
programming directly in a DAW :) The UI could do with quite a bit of
love (it's really OK for an initial release), but DrMr is already a
huge win for me.
> But yes, kit customization is in the pipeline, although behind getting the
> core solid and stable.
What are the top priorities for you right now?
Alexandre Prokoudine
http://libregraphicsworld.org
Hi all,
I have been running SooperLooper in headless mode on netbook. I don't have
X installed on it and just control SooperLooper (SL) via MIDI and OSC.
Occasionally I get some clicks which I hadn't experienced when running it
with GUI on my laptop. I have tried playing with the SL setting but can't
really avoid this happening. I think it may have something to do with the
combination of low spec processor and crappy audio card (I had to compiled
linux-rt to get it to work reasonably at all).
So I wanted to run it through a declipper/noise gate, until I get a better
machine or audio card. I know there is a LADSPA one available but all the
LADSPA hosts seem to have a GUI.
Is there a LADSPA host that doesn't require running X?
Regards,
Kaspar
Hey all,
I'm currently trying to fix the reverb in Luppp and I'm running into a
rather strange bug:
I have an array of floats that is used to set the plugins parameters: its
called controlBuffer.
The following code connects the ports to the addresses of the float buffer.
The crazy thing is: The print outs before & after the connect ports are
different!
I don't understand how this is possible, but perhaps I'm missing something
LADSPA.
cout << "Decay: " << controlBuffer[4] << " Wet: " << controlBuffer[8]
<< " Dry: " << controlBuffer[9]
<< " preDelay: " << controlBuffer[10] << " highDamp " <<
controlBuffer[5] << endl;
descriptor -> connect_port ( pluginHandle , 0 , buffer );
descriptor -> connect_port ( pluginHandle , 1 , buffer );
descriptor -> connect_port ( pluginHandle , 2 , &outputBuffer[0] );
descriptor -> connect_port ( pluginHandle , 3 , &outputBufferR[0] );
descriptor -> connect_port ( pluginHandle , 4, &controlBuffer[4] );
descriptor -> connect_port ( pluginHandle , 5, &controlBuffer[5] );
descriptor -> connect_port ( pluginHandle , 6, &controlBuffer[6] );
descriptor -> connect_port ( pluginHandle , 7, &controlBuffer[7] );
descriptor -> connect_port ( pluginHandle , 8, &controlBuffer[8] );
descriptor -> connect_port ( pluginHandle , 9, &controlBuffer[9] );
descriptor -> connect_port ( pluginHandle ,10, &controlBuffer[10] );
descriptor -> connect_port ( pluginHandle ,11, &controlBuffer[11] );
descriptor -> connect_port ( pluginHandle ,12, &controlBuffer[12] );
cout << "Decay: " << controlBuffer[4] << " Wet: " << controlBuffer[8]
<< " Dry: " << controlBuffer[9]
<< " preDelay: " << controlBuffer[10] << " highDamp " <<
controlBuffer[5] << endl;
Example Output:
Decay: 4.7685 Wet: 0.70709 Dry: 0.696707 preDelay: 50 highDamp 0
Decay: 1.5 Wet: 0.25 Dry: 1 preDelay: 0 highDamp 5000
The problem is that the reverb plugin doesn't react to my input parameters,
but just processes based
on the 1.5, 0.25 wet, preDelay 0, and highDamp 5000 *all* the time, and
there's nothing I can do about it.
Am I doing something fundamentally wrong? I've tried connecting the ports
every process(), once, and then leave them.
I've hard coded values, it seems to make no difference.
These are the two relevant sources:
https://github.com/harryhaaren/Luppp/blob/master/src/ladspahost.hpphttps://github.com/harryhaaren/Luppp/blob/master/src/ladspahost.cpp
Help appreciated! -Harry
It's official I'm selling the real Ardour Tablet
With so many discussions about Ardour and real audio apps running on a
Tablet, I decided to offer for sale the original Trinity DAW.
Funds are going straight to help moms dementia treatment.
You can purchase on ebay or at Indiegogo by making the 1000.00
contribution. Just send me an email where to send the merchandise.
ronaldjstewart(a)gmail.com
Shipping Worldwide
Rock on Linux Pro Audio! and thank again to everyone!
Ronald Stewart
Indiegogo donation page:
http://www.indiegogo.com/Cure-My-Moms-Dementia-Today?a=398903
Ebay page: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=250994835490
Fixed in this version:
- Compilation bug due to missing gdkconfig.h file
The Newtonator is an LV2 soft synth that uses a unique algorithm based on
simple ideas of velocity and acceleration to produce some unpredictable
sounds. More documentation can be found on the project website at
http://newtonator.sf.net/.
Thanks,
Michael Bechard
