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
hi *!
whatever i do, i can't seem to get any data from an audio input port in
my lv2 plugin. i made local copies of all buffer pointers (even though
that shouldn't be necessary iirc), and in case ardour does in-place
processing, i always cache sample N before writing it to the first
output, so that i still have it available for the other outputs.
i even set lv2:inPlaceBroken, but no luck. now i was beginning to
suspect i'm very very stupid, but then i installed the eg-amp.lv2 plugin
(the simple amplifier example from the lv2core repository, which i've
used as a template for my own code), and hey presto: no signal either.
what the fu..ndamental problem might be, i can't say.
any insights most welcome.
thanks,
jörn
Hello all,
Now available on
<http://kokkinizita.linuxaudio.org:/linuxaudio/downloads>
Zita-lrx - First release 05/01/2012
------------------------------------
Zita-lrx is a command line jack application providing 2, 3, or 4-band,
4th order crossover filters. The filter type is continuously variable
between Linkwitz-Riley (-6dB at the xover frequency) and Butterworth
(-3 dB at the xover frequency). Outputs are exactly phase matched in
the crossover regions.
The application supports up to 16 channels. This is a compile time
limit and easily changed, but if you have many channels it may be
a better idea to use two or more instances in order to spread the
load in an SMP system. Not that it would matter much - on my old
2 GHz P4, CPU load is around 0.6% per channel for four bands.
Configuration is by a text file using 'OSC' style syntax (similar
to Ambdec and Jconvolver). Apart from the basic filter parameters,
the following can be set:
- Channel labels (used for naming Jack ports).
- Frequency band names (used in output port names).
- Optional output autoconnections.
- For each channel: gain and delay (in ms).
- For each frequency band: gain and delay.
Enjoy !
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Hi, recently I found libinstpatch in debian repository. How can I read a
Instrument with this library? Please take a look at
sourceforge.net/projects/ags.
libinstpatch will be initialized in main function.
The following functions are involved:
gboolean
ags_ipatch_open(AgsPlayable *playable, gchar *filename);
gboolean
ags_ipatch_sf2_reader_open(AgsPlayable *playable, gchar *filename);
void
ags_ipatch_sf2_reader_level_select(AgsPlayable *playable,
guint nth_level, gchar
*sublevel_name,
GError **error);
void
ags_ipatch_sf2_reader_iter_start(AgsPlayable *playable);
gboolean
ags_ipatch_sf2_reader_iter_next(AgsPlayable *playable);
void
ags_ipatch_sf2_reader_info(AgsPlayable *playable,
guint *channels, guint *frames,
guint *loop_start, guint *loop_end,
GError **error);
short*
ags_ipatch_sf2_reader_read(AgsPlayable *playable,
guint channel,
GError **error);
then it will be translated to ags format AgsAudioSignal by:
GList*
ags_playable_read_audio_signal(AgsPlayable *playable,
AgsDevout *devout,
guint start_channel, guint
channels_to_read);
Forgot to send to list also:
On Fri, 3 Feb 2012 14:48:37 +0100
Nick Copeland <nickycopeland(a)hotmail.com> wrote:
>
> You probably need something like -I/usr/lib/faust which will give you
> the final path of /usr/lib/faust/gui/FUI.h, you might also want to
> try -I. if the headerfiles are also in $CWD/gui Either way, I am not
> certain you would find it with -L/-l (upper/lower case) sinceit looks
> like an include file rather than a library.
>
ok, it seems it gets past that but I get another error:
$ g++ -I/usr/lib/faust -o simple simple.cpp
In file included from simple.cpp:48:0:
/usr/lib/faust/gui/faustqt.h:34:24: fatal error: QApplication: No such file
or directory
compilation terminated.
On 02/01/2012 12:16 PM, rosea.grammostola wrote:
> Interesting. Would be nice if you could use SuperCollider code (synths)
> as LV2 plugins too. Or is it naive to think that such a LV2 plugin
> (supercollider-lv2) would make much more sofsynths available for the
> linux platform?
That's certainly possible. But the synthdefs are only part of the story.
Many SC instruments are highly customized and dynamic networks of signal
processing components driven by sclang code. I'm not sure how you would
map those to standalone components in an LV2-based environment where
audio and control ports are (mostly) static.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
