Re: [LAD] [LAA][ANNOUNCE] New LV2 Soft Synth: The Newtonator v0.5.0
On Fri, Aug 19, 2011 at 10:00 PM, Michael Bechard gothma...@yahoo.comwrote: Also, I'm not familiar with lv2host (can't find it in Synaptic...), could you point me at the version you're using? zynJackU: 6-0tstudio2 (thats from the TangoStudio repo) Apologies, with lv2host I meant Lv2Rack, which i think is based on zynJackU, (or partially uses its code), as it mentions zynJackU in the backtrace. Probably to do with the manifest file, the backtrace is pretty much identical. Upon testing with lv2_jack_host the plugin works gets instantiated ok, and is running in the jack graph. Haven't played with it yet though... Cheers, -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Inter thread Communication: Design Approach
Hey All, I'm looking to improve a program's design with regards to how it communicates between the jack thread and its main/gui thread. Please note I'm *not* looking for implementation details like what ringbuffer to use, this has been discussed here before. Conditions: Gui needs to feed data trough to the jack thread (data = parameter moves etc) Jack thread needs to push data (buffers for waveforms playhead info) The real question: What is a neat solution to passing various data trough a ringbuffer? My (hacky?) solution: Create a class, call it Event. Runtime now looks like so: 1. Create a EventType enum, set the details 2. Write those Events into the ringbuffer 3. Switch based on EventType, and handle the event. While not terribly ugly, that Event class starts to get bigger nastier, so I concidered sub-classing it... but I'm not sure this is going in the right direction. I'm very intrested how the big programs around have approached this problem... Cheers, -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Inter thread Communication: Design Approach
On 08/20/2011 09:19 AM, Harry van Haaren wrote:
My (hacky?) solution: Create a class, call it Event. Runtime now looks
like so:
1. Create a EventType enum, set the details
2. Write those Events into the ringbuffer
3. Switch based on EventType, and handle the event.
While not terribly ugly, that Event class starts to get bigger
nastier, so I concidered sub-classing it... but I'm not sure this is
going in the right direction.
IMHO, You're more or less going in the right direction. There's two
main ways to structure your EventType.. and they are both essentially
using inheritance. We'll call them The C way and The C++ Way. They
are more or less equivalent.
Consider the following to be pseudocode. I didn't test it.
THE C WAY
=
struct base_event_t_ {
uint16_t type;
uint16_t size;
};
typedef struct base_event_t_ base_event_t;
#define EVENT_ONE 1
struct event_one_t_ {
uint16_t type;
uint16_t size; /* must be EVENT_ONE */
/* extra event-specific data */
};
typedef struct event_one_t_ event_one_t;
#define EVENT_TWO 2
struct event_two_t_ {
uint16_t type;
uint16_t size; /* must be EVENT_TWO */
/* extra event-specific data */
};
typedef struct event_one_t_;
/* ... */
void my_function(event_t *ev)
{
switch(ev-type) {
case EVENT_ONE:
handle_event_one( (event_one_t*) ev );
break;
case EVENT_TWO:
handle_event_two( (event_two_t*) ev );
break;
}
}
DISADVANTAGE: You have to manually manage the type and size arguments.
THE C++ WAY
===
class event_t
{
public:
enum {
EVENT_ONE = 1,
EVENT_TWO = 2
}; /* note: using an enum isn't necc. */
virtual ~event_t() {}
int type() = 0;
uint32_t size() = 0;
};
class event_one_t : public event_t
{
public:
int type() { return int(EVENT_ONE); }
uint32_t size() { return sizeof(event_one); }
/* event-specific stuff */
};
class event_two_t : public event_t
{
public:
int type() { return int(EVENT_TWO); }
uint32_t size() { return sizeof(event_two); }
/* event-specific stuff */
};
/* ... */
void my_function(const event_t ev)
{
switch(ev-type()) {
case event_t::EVENT_ONE:
handle_event_one( dynamic_castconst event_one_t(ev) );
break;
case event_t::EVENT_TWO:
handle_event_two( dynamic_castconst event_two_t(ev) );
break;
}
}
DISADVANTAGE: Using dynamic_cast uses RTTI and can have a performance
penalty... but guards against programming mistakes (throwing an
exception if cast is invalid). Switch to reinterpret_cast if speed is
a problem.
-gabriel
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Inter thread Communication: Design Approach
On Saturday 20 August 2011 17:04:46 Gabriel Beddingfield wrote: DISADVANTAGE: Using dynamic_cast uses RTTI and can have a performance penalty... but guards against programming mistakes (throwing an exception if cast is invalid). Switch to reinterpret_cast if speed is a problem. This performance penalty might hit you when you do one such message for every sample of audio, it will have no practical effect when its just the user interface signaling other parts of the app. Have fun, Arnold signature.asc Description: This is a digitally signed message part. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAA][ANNOUNCE] New LV2 Soft Synth: The Newtonator v0.5.0
Ok, glad to hear lv2_jack_host seems to be working, let me know how it goes. Regarding lv2rack, that is an effects host, not a synth host, so yeah, it'll crash if it tries to load The Newtonator :) Thanks, Michael Bechard From: Harry van Haaren harryhaa...@gmail.com To: Michael Bechard gothma...@yahoo.com Cc: Linux Audio Developers List linux-audio-dev@lists.linuxaudio.org Sent: Saturday, August 20, 2011 5:57 AM Subject: Re: Re: [LAD] [LAA][ANNOUNCE] New LV2 Soft Synth: The Newtonator v0.5.0 On Fri, Aug 19, 2011 at 10:00 PM, Michael Bechard gothma...@yahoo.com wrote: Also, I'm not familiar with lv2host (can't find it in Synaptic...), could you point me at the version you're using? zynJackU: 6-0tstudio2 (thats from the TangoStudio repo) Apologies, with lv2host I meant Lv2Rack, which i think is based on zynJackU, (or partially uses its code), as it mentions zynJackU in the backtrace. Probably to do with the manifest file, the backtrace is pretty much identical. Upon testing with lv2_jack_host the plugin works gets instantiated ok, and is running in the jack graph. Haven't played with it yet though... Cheers, -Harry___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Inter thread Communication: Design Approach
On Sat, Aug 20, 2011 at 4:04 PM, Gabriel Beddingfield gabrb...@gmail.comwrote: IMHO, You're more or less going in the right direction. There's two main ways to structure your EventType.. and they are both essentially using inheritance. We'll call them The C way and The C++ Way. They are more or less equivalent. Thanks for that! I like the C++ way, it seems more in line with my way of doing things... I spose I just gotta go derive some classes now :) Cheers, -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
2011/7/20 Kai Vehmanen kvehma...@eca.cx: PS My plan B is to wait and see for another 10 years (and many more long threads about this topic on this list), and then I can at least just start using C++0x already... ;) It's called C++11 now and accepted by ISO already ;) 2011 April 11 --- C++11, passed review by the technical standards committee: http://www.physorg.com/news/2011-04-c11-iteration-language.html The biggest changes: http://www.softwarequalityconnection.com/2011/06/the-biggest-changes-in-c11-and-why-you-should-care/ I've never particularly liked C++ (syntax and complexity) though and would prefer a different language to be spread. Technologies as Mono and LLVM appear to make that possible. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] a *simple* ring buffer, comments pls?
On 08/20/2011 01:24 PM, Emanuel Rumpf wrote: 2011/7/20 Kai Vehmanenkvehma...@eca.cx: PS My plan B is to wait and see for another 10 years (and many more long threads about this topic on this list), and then I can at least just start using C++0x already... ;) It's called C++11 now and accepted by ISO already ;) Nope. First line in TFA: Barring unforeseen delays the official standard will be approved in the fall. (translation: not quite yet.) -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
