Hi there,
This may be a very simple question, I am not sure.
I am hacking on a buzz-like tracker, aldrin. It is written in
Python, but the heavy lifting is done by libzzub, which uses
portmidi for midi implementation.
At the moment, midi in devices can be selected, midi out are a
bit buggy, but I think that should not be too difficult to sort
out. The main problem which I would like help with, is that the
midi inputs and outputs from aldrin do not show up in with
aconnect -lo or -li at all..
Is it possible to get portmidi to work with alsa correctly in
this way, or are midi connections always handled within the
program, connecting to alsa devices, but invisible to aconnect?
The source for both projects is at:
http://trac.zeitherrschaft.org/aldrin/browserhttp://trac.zeitherrschaft.org/zzub/browser
All the best,
James
I am looking for someone with device driver experience to implement an
audio-over-ethernet protocol on Linux. This is a short-term paid
position; the license and basic architecture of the driver is not yet
decided. If you're interested, get in touch with me.
thanks,
--p
Hello all,
A few weeks ago there was a discussion about proposed enhancements to
Lars Luthman's LV2 MIDI port extension (lv2-midiport.h). I've read the
suggestions that you gave, and tried to hack together a new version,
that would enhance the initial standard that Lars designed, by:
- addressing alignment-related issues
- using fixed-point integers for time values
- adding optional sub-channel addressing (for per-note control changes
and similar features)
- optionally allowing sending floating point automation events in the
same stream as MIDI events (because mixing several event streams at the
same time is inefficient)
- optionally allowing sending arbitrary data (similar to SysEx, but
fully binary safe and without having to pay to register at MMA :) )
- trying to keep it simple, efficient and easy to implement
Finding the right compromise is often an impossible task, so it won't
probably satisfy everyone. However, I think its advantages outweight
those of its drawbacks and limitations that I can currently see. The
basic MIDI-type events can be passed with minimal effort, however, the
more advanced features require more effort if you want to make use of
them (though they may be safely ignored).
Here we go - treat it as pseudocode sketch meant to get more feedback
from you, not as the compilable C code (that's why there is no license
or copyrights attached, in case anybody's wondering). In fact, there's
no actual *code* (as in: anything that translates into CPU instructions)
here, just data structures and declarations. Also, because it is not
meant to be actually used at this stage, I'm not assigning it any URI.
// data structures for proposed "enhanced event port" extension of LV2
audio plugin standard
// loosely based on Lars Luthman's lv2-midiport.h; most ideas come from
people on
// linux-audio-developers mailing list (David Olofson, Lars Luthman,
Stefan Westerfeld,
// Nedko Arnaudov and others)
// base event structure
// size: 8 octets
// if command < 0x80, one more 8-octet structure follows; the type of that
// structure is dependent on value of command
// the plugin that does not understand the given command can safely skip
the next 8 bytes
struct LV2_EVENT_HEADER
{
uint32_t timestamp; ///< fixed-point timestamp with 16 integer and 16
fractional bits; use of fractional part is optional
uint8_t command; ///< command byte - >= 0x80 for MIDI commands,
<0x80 for 16-octet extended commands
uint8_t arg1; ///< for MIDI commands that need it; should be 0
otherwise
uint8_t arg2; ///< for MIDI commands that need it; should be 0
otherwise
uint8_t subchannel; ///< optional, allows for control changes for
specific notes; writer must set to 0 if not used
};
// buffer of events, analogous to LV2_MIDI structure in Lars Luthman's
extension
struct LV2_EVENT_BUFFER
{
LV2_EVENT_HEADER *first; ///< pointer to the first event, the next
ones (if any) follow it directly
uint32_t event_count; ///< number of events in the buffer
uint32_t block_count; ///< buffer size (current or max, depending on
if it's input or output buffer) in 8-octet blocks
};
// the features below are optional and may be ignored by skipping the
8-octet extension block
// optional command 0x70: set parameter
struct LV2_EVENT_EXT_FLOAT
{
uint32_t lv2_ctl_port;
float new_value;
};
// feel _encouraged_ to ignore everything below this line ;)
// advanced optional command 0x71: set parameter delta
// specifies that until the next event the parameter
// is supposed to increase linearly by new_value_delta each sample
// this is for super-precise envelopes and other insane paranoid stuff :)
struct LV2_EVENT_EXT_FLOAT_DELTA
{
uint32_t lv2_ctl_port;
float new_value_delta;
};
struct LV2_BINARY_BUFFER;
struct LV2_BINARY_BUFFER_FUNCTIONS
{
// increase reference count and return data pointer
const char *(*ref_inc)(struct LV2_BINARY_BUFFER *self);
// decrease reference count
void (*ref_dec)(struct LV2_BINARY_BUFFER *self);
// get event type URI or MIME type
const char *(*get_type)(struct LV2_BINARY_BUFFER *self);
// get string encoding (if applicable)
const char *(*get_encoding)(struct LV2_BINARY_BUFFER *self);
};
struct LV2_BINARY_BUFFER
{
// pointer analogous to virtual method table pointer
LV2_BINARY_BUFFER_FUNCS *funcs;
// length of data in octets
uint32_t length;
};
// advanced optional command 0x72: data block
// in order to get to the data, ref_inc must be used before
// process function ends (and then use ref_dec to free the data)
// otherwise host will free or reuse it to avoid leaks
struct LV2_EVENT_EXT_BINARY
{
union {
uint64_t pad; // padding so that the structure is 64 bits long
LV2_BINARY_BUFFER *bb;
};
};
---
Have fun :)
Krzysztof
Hello again,
I've coded a module to use the fast_lookahead_limiter plugin. Upon
using the LADSPA plugin's run function, it segfaults. gdb reveals:
(gdb) step
runFastLookaheadLimiter (instance=0x80de1d8, sample_count=1) at
fast_lookahead_limiter_1913.xml:79
79 fast_lookahead_limiter_1913.xml: No such file or directory.
in fast_lookahead_limiter_1913.xml
Current language: auto; currently c
---
I can't find any information about this. I don't understand or know why
it needs to access the xml file. I don't what I am meant to do to make
sure it finds it, or even where it's meant to be.
There was no such problem implementing GLAME Butterworth filters. How
I'm meant to tell?
Cheers,
James.
Hi,
I'm attempting to use dlsym to dynamically load a ladspa plugin lib in
c++. I've found various web pages describing how to use dlsym in c++
but they do not seem entirely relevant to using ladspa (ie ladspa
plugins are mainly written in c) (??).
I've also looked at some ardour src, but somehow it seems to use, in a
c++ file, the c method which should not work (!?). I also looked within
hydrogen src, but that seems to use QT(?) to do the loading - and
delving into the QT src code does not appeal right now ;-)
Anybody know where could I find some simple c++ source examples for
loading ladspa plugins?
Cheers,
James
Christian Schoenebeck cuse at users.sourceforge.net:
>Am Donnerstag, 15. November 2007 18:51:30 schrieb Kjetil S. Matheussen:
>> *The msys terminal is a lot nicer than xterm
>> *msys/mingw uses fewer resources than cygwin
>> *mingw executables requires fewer dlls and are easier to
>> distribute
>> *mingw executables can be linked with non-cygwin dll's.
>>
>> disadvantages:
>> *msys/mingw is messy to set up. Check out the FAQ first.
>> *msys/mingw is very messy to upgrade.
>> (manually unpacking .tar files into the file tree)
>> *msys doesn't provide the same amount of unix tools.
>> *mingw executables can not be linked with cygwin dll's.
>
>That's not a real either/or question. Mingw is part of Cygwin as well:
>
> http://cygwin.com/packages/
>
>So you can easily setup and update both with just a few clicks in the
>cygwin
>install utility.
Sure, but then you have to use the -mno-cygwin option to gcc
when compiling, which sometimes can be tricky. So my comparison
above is still valid, and you don't need cygwin to run mingw.
The msys terminal is very nice, and I don't see any reason
to fire up the whole cygwin[1] beast to compile a native
windows app now and then, unless you need something in
cygwin which is not provided by msys of course.
I also think its messy to mix the mingw and cygwin
environments, since they are not compatible. Its easy to
link with libraries of the other type (ie. compiling
with mingw and link with cygwin libraries, or compiling
with cygwin and link with mingw libraries), and then
strange things can happen. Its better to keep the two
environments in separate installations if you can.
At least thats my experience.
[1] X running inside windows is required to make working
with cygwin somewhat comfortable
>One thing I wonder is whether mingw has any disadvantages regarding
>compiler
>optimizations?
No, that would be very strange.
> You know the term "minimalistic" in its name raises such
>doubts.
I wouldn't worry about that. Gcc is gcc.
>Maybe... I considered Control as well, but to me, both of those sound
more like single instances of something (just like Ports), rather
than the Class/Type style (ie "Voice Pitch Controls") term I'm
looking for.
>*Some* plugin API or something somewhere must have something similar
to this, I'd think, but I can't remember seeing one...
My plugin API has parameters , pins ( similar to ports ) and 'voices'.
The relationship is that parameters map to pins, and controllers map to
pins.
For example:
pin 0 - "Master Volume" (parameter, monophonic).
Pin 1 - "Note Pitch" (controller, polyphonic, mapped to MIDI
Note-On/Pitch).
Pin 3 - "Tempo" (monophonic, mapped to host tempo).
The host decodes MIDI and maps controllers to pins. The plugin API need not
support MIDI at all (yay!), you could migrate to using OSC messages just as
easily with no change to your plugin code.
The end result is that the plugin API is *very* minimal, 3 functions support
most of the GMPI requirements...
class IMpPlugin : public IMpUnknown
{
public:
// Processing about to start. Allocate resources here.
virtual int32_t MP_STDCALL open() = 0;
// Notify plugin of audio buffer address, one pin at a time. Address
may change between process() calls.
virtual int32_t MP_STDCALL setBuffer( int32_t pinId, float* buffer )
= 0;
// Process a time slice. No Return code, must always succeed.
virtual void MP_STDCALL process( int32_t count, MpEvent* events ) =
0;
};
Jeff
David Olofson:
>> And last:
>>
>> If I can only do it native Windows, what do I need in the way of
>> compiler etc. ?
>
> Cygwin is probably the easiest way to get started with that, whether
> you're using Wine or Windows:
> http://www.cygwin.com/
>
I depends. For hardcore unix programs, cygwin can in some situations
be the only alternative. But msys/mingw has its advantages as well:
*The msys terminal is a lot nicer than xterm
*msys/mingw uses fewer resources than cygwin
*mingw executables requires fewer dlls and are easier to
distribute
*mingw executables can be linked with non-cygwin dll's.
disadvantages:
*msys/mingw is messy to set up. Check out the FAQ first.
*msys/mingw is very messy to upgrade.
(manually unpacking .tar files into the file tree)
*msys doesn't provide the same amount of unix tools.
*mingw executables can not be linked with cygwin dll's.
http://www.mingw.org/msys.shtml
Not sure if this is a hard problem, or if I'm just being extra stupid
today...
Assume we have a 2D addressing scheme for addressing Ports on a
plugin. A Port here can be a connection that sends or receives a
single mono audio stream, control data for a single parameter, or
something like that.
The first dimension is similar to MIDI CCs, or the different types of
controls in a mixer strip. The coordinate indicates what kind or
group of control/port/whatever we're talking about. Examples: "Master
volume control" (probably just one of these) and "channel pitch
controls" (one per channel, obviously). On a (normal) studio mixer,
we'd be talking about a horizontal row of controls, all of the same
kind.
The second dimension is similar to MIDI channels, synth voices, or
mixer channels, depending on context. I'm calling all this "Channel",
as that's the least domain specific name I can think of that still
makes sense. Basically, when you have multiple indentical internal
objects, this is how you address the instances.
Now, what do I call the first dimension, *before* specifying what
channel I'm talking about? How do I address "the Volume CCs of all 16
MIDI channels", or "the PFL buttons of all mixer strips?" I'd like a
short, logical, non-confusing name for this, but I can't seem to
think of one.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
David Olofson <david(a)olofson.net> writes:
> On Monday 05 November 2007, Nedko Arnaudov wrote:
>> Purpose of this LV2 extension is to standardize realtime safe
>> allocations in a plugin. Plan is, host to provide functions that
>> plugin can call. Pointers to functions are provided through host
>> feature. Only memory pool (fixed chunk size) functionality is
>> defined.
>>
>> Attached is early draft of the header. Doxygen generated from it
>> documentation is available at:
>>
>>
> http://svn.gna.org/viewcvs/*checkout*/lv2dynparam/website/doxygen/lv2__rtme…
>>
>> Any comments are welcome. In particular about whether general
>> purpose allocator (arbitrary memory chunk size) should be part of
>> this same extension.
>
> I'm not quite sure I see the point of having hosts provide this level
> of functionality. A pool of fixed size chunks is trivial to implement
> on the plugin side.
>
> The only obvious advantage I see is the potential transparent host
> side sharing of memory across plugins - but this gets tricky to
> implement when plugins request different chunk sizes. Sure, the host
> can split and merge chunks and stuff as needed, but then you may as
> well go all the way, as you'll need a real memory manager behind the
> scenes anyway.
The point is that some plugins need *realtime safe* memory allocation. I
need this functionality for lv2zynadd plugin (like arbitrary voices
count allocation) and for lv2dynparam plugin library internal operation
too. There were rumors in #lad that such functionality may be useful
without lv2dynparam extension. This has lead to this proposal. But if
there are no positive opinions for this extension I'll integrate it into
lv2dynparam extension.
That reminds me that LV2 may need a way to specify optional features
that interdepend. I.e. features (extensions) A and B are both optional
but if A is provided B is required. Of course plugin can check this
explicitly on instantiate and refuse to use feature, but I'm not sure
how vital is such approach.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
