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
Hi,
try to brush up a bit Minicomputer software synthesizer which is in a
bet shape. I have all sorts of redraw problems with FLTK, seems it
started with FLTK 1.3, does anyone experienced similar things and has
some tips to share? Google gave nothing, seems I am the only one.
Cheers,
Malte
--
----
media art + development
http://www.block4.com
Hi all, seeking opinions:
I have to choose a way to represent beat-based tempo time in 64 bits.
Uses are many, but the main one is event time stamps for plugins.
Requirements:
* No odd data sizes (for performance / programmer ease)
* High precision (ideally close to sample accurate for most tempos)
* Fits in the same space as two uint32_t's
Questions:
* Is "bar" needed?
* Use floating point? Rounding errors an issue?
Options:
/* A (moderate range, ultra precise) */
struct {
uint16_t bar;
uint16_t beat;
uint32_t tick;
};
/* B (high range, moderate precision) */
struct {
uint32_t bar;
uint16_t beat;
uint16_t tick;
};
/* C (high range, good precision?) */
struct {
uint32_t bar
float beat;
};
/* D (high range/precision, but no bar) */
double beat;
I havn't run the math on precision yet, but I am leaning towards C. I
actually hadn't considered mixing int and float before writing this
email, but it seems the best trade-off, and working with float is
certainly more pleasant than fixed point.
Thoughts?
-dr
Hi, I'm learning to write simple audio/midi applications in C++ with
RtMidi and gtkmm libraries (version 2.4).
This is the application I'm working on:
http://www.eclepticbox.altervista.org/index.php/download/finish/2-audio-mid…
I got some issues with RtMidi IN (Callback). I followed the RtMidi
tutorial and the VMPK example (however this is written with Qt), but the
problem is that the GUI freezes when I send some MIDI data and it
doesn't refresh the widgets values.
Midi Out works properly.
I think the problem is in the Midi Callback and in the event/signal
managing.
I tried some function in order to refresh the gui but they didn't work.
This is the smallest extract of code that has the issue (only a
spinbutton sending / receiving MIDI Program Change):
http://www.eclepticbox.altervista.org/index.php/download/finish/2-audio-mid…
The sources are in the src folder, see:
sawlidsyngui.cpp
sawlidsyngui.h
Any help is appreciated....
Thanks ...
Alessandro
hi *!
total lv2 newbie trying to get my feet wet, so bear with me :)
i'm trying to dezip my control ports by using simple linear
interpolation. to that end, i'm storing the current values of all
control ports in extra fields in the LV2_Handle.
they get ramped to the desired value during run(), so that the current
values will equal the ones set by the control ports at the end of each
run().
now i'm stuck trying to understand where to initialize my current value
fields.
what i want to avoid is a ramp from default or previous values whenever
the plugin is run for the first time. in that case, i want to have no
ramp and start cold with the control port value.
can i rely on control port data being available during activate() so
that i can initialize my current values to the control port values?
now i could set the current values to NULL during instantiate and
deactivate, but then i'd have an extra conditional in run(), which i'd
like to avoid.
what is the recommended procedure to deal with this?
jörn
Hello,
I am working on the successor to the event extension and its
EventBuffer. This is the buffer used for MIDI in LV2 instruments and
such[1].
I need to know:
* Does anyone actually use the variable time stamp type stuff? The
original idea here was to support tempo time, but it seems unlikely
anyone will do that in run()
* Does anyone use the event_count field for anything other than
iterating over the events? It would be nice to remove this.
* Does anyone need the ability for the buffer payload to be not in the
same POD chunk as the header? I would be nice to remove this pointer
and have the buffer be a POD chunk like everything else. The original
idea was so e.g. hosts could make plugins write to fragments of other
buffers, but I can't think of a real use for this, and radical
simplification is the name of the game here.
* Is anyone actually using non-POD events and references?
If anyone has any other gripes/suggestions for the event extension,
now's the time to make them heard. Speak now or forever hold your
peace, etc.
Thanks,
-dr
P.S. I have avoided the "why does event need to be replaced" part to
keep it to the point, but if anyone is curious, I can explain