On Mon, 16 Sep 2013 18:34:17 -0600
Burkhard Ritter burkh...@ualberta.ca wrote:
My understanding now is that: 1. Atomicity
(meaning atomic read and write) in and by itself is not enough. I also
need to ensure that memory access does not get reordered across my
atomic reads and writes (so that,
On Tue, Sep 17, 2013 at 2:25 AM, Alexandre DENIS
cont...@alexandredenis.net wrote:
For atomic read/writes, barriers, and other atomic operations,
cpu-specific instructions are not needed anymore. You can use generic
gcc builtins:
http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Atomic-Builtins.html
Hi Tim,
thanks, that was very helpful. Unfortunately, I am only now finally
getting back to looking into this again.
On Tue, Aug 27, 2013 at 11:50 AM, Tim Goetze t...@quitte.de wrote:
It's been a while since I did some research: IIrc on i386, 32-bit read
or write access is atomic if the
[Burkhard Ritter]
I've considered different approaches (separate data for each thread,
various versions of shared data), but I believe all of them make at
least two assumptions: That reading and writing byte-sized data (e.g.
a bool flag) and that updating pointers is atomic. I got a bit
confused
Hi all,
I just joined the developers list as I've been looking into adding
Jack midi support to one of my favourite sequencers (harmonySEQ) and
need some advice related to threading and shared data. I know these
issues have come up before, specifically I found two related threads
[1][2], but I am
say you want to create a software synthesizer. With jack midi you can
do all processing in the jack callback.
If you use alsa midi, you need an extra realtime thread to collect and
time stamp alsa midi events and some form of non blocking interprocess
communication between the midi thread and jack
On Thu, Feb 07, 2008 at 03:31:53PM +0100, Werner Schweer wrote:
say you want to create a software synthesizer. With jack midi you can
do all processing in the jack callback.
If you use alsa midi, you need an extra realtime thread to collect and
time stamp alsa midi events and some form of non
i was following the discussion on technical details.. it was
interesting and i learnt a few things.. still not enough to put it
into any code..
i sort of sorted out what is the jack-midi about but was trying to
play a bit stupid (sometimes i can't stop that game even when i want
;)) and fnd
for example, if one needed a higher resolution for a note-on events
velocity,
the event could be followed by a sysex data with one or two additional
7-bit values. (kind like it's already done with MSB and LSB for some
controller values)
one word: NRPN. thats what its there for.
;
--
On Thu, Jan 17, 2008 at 04:00:01PM -0500, Dave Robillard wrote:
If anyone is seriously considering throwing Jack MIDI API out the
window, look at the LV2 event header here (just LV2_Event, ignoring the
type number mapping to URI bit):
I'm NOT proposing to throw it out, in fact my ramblings
On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien Claassen wrote:
Why can't those people who discussed it here (Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API - as
it is - and try to work this new concept around it.
Well, the two you
Fons Adriaensen wrote:
On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien Claassen wrote:
Why can't those people who discussed it here (Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API - as
it is - and try to work this new concept around
Am Freitag, 18. Januar 2008 01:28:28 schrieb Dave Robillard:
There are plenty of people using it, and the API is stable as of 0.109.0
- it's definitely not changing (again) in Jack 1. The existing one is
fine for the uses intended anyway (if you're doing massive sysex dumps,
don't use Jack)
On Fri, 2008-01-18 at 14:27 +0100, Fons Adriaensen wrote:
On Fri, Jan 18, 2008 at 02:07:26PM +0100, Albert Graef wrote:
Fons Adriaensen wrote:
Seriously, there are three things that I profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
some of the things mentioned could be done by simply extending the
midi specification.
for example, if one needed a higher resolution for a note-on events velocity,
the event could be followed by a sysex data with one or two additional
7-bit values. (kind like it's already done with MSB and LSB
On Fri, Jan 18, 2008 at 02:07:26PM +0100, Albert Graef wrote:
Fons Adriaensen wrote:
Seriously, there are three things that I profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
On Fri, 2008-01-18 at 13:09 +0100, Fons Adriaensen wrote:
On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien Claassen wrote:
Why can't those people who discussed it here (Dave R., Fons and probably
more - simply sit down and try to take as much as possible from the API -
as
it is -
Fons Adriaensen wrote:
Seriously, there are three things that I profoundly dislike in MIDI.
1. The limited precision of almost all values, 7 bits or 14 with a
kludge (but even this kludge is not available in any standard
way for e.g. individual note frequencies).
Agreed. The MIDI
On Wed, Jan 16, 2008 at 01:32:32PM -0500, Paul Davis wrote:
so, fons, you're proposing one or both of:
1) that this community somehow magically defines a new standard
for musical information, despite the complete failure of
the entire field of music technology to do this
On Wed, 2008-01-16 at 14:43 +0100, Fons Adriaensen wrote:
With the release of Jack 0.109 we now have a (hopefully)
stable API for midi-over-jack. This set me to consider what
would be required to modify Aeolus to use this system.
And I did not like the conclusions.
Is it a good idea to
and the technical ignorant again.
Correct if I'm far wrong: lv2 does roughly contain what you were looking
for.
The LV2 API is (at least mechanically or whatevfer) not to far from the JACK
MIDI approach.
About the format being float or what, having to be converted to 7BIT
MIDI-controls:
With the release of Jack 0.109 we now have a (hopefully)
stable API for midi-over-jack. This set me to consider what
would be required to modify Aeolus to use this system.
And I did not like the conclusions.
Is it a good idea to insert a 30-year old data format
that mixes real-time and general
On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter Palmers wrote:
I guess you will agree if I state that it would have been better if you
performed this though experiment while the API was still in a volatile
stage. But that observation doesn't help us, so let's not go down that
path. (FWIW
Hi Paul!
Pardon me, being technically far from even OK. But I think especially this
sysex thing is important. Consider a real studio (home or pro), there are
still a lot of external devices, which occasionally need to receive sysex
(special program banks, sample updates). For me this is an
Hi Julien!
On Jan 16, 2008 8:25 PM, Julien Claassen [EMAIL PROTECTED] wrote:
(special program banks, sample updates). For me this is an issue and I believe
I'm not alone there.
You are perfectly right!
So: did you consider extending, pollishing the API so this is possible or
would you have
Fons Adriaensen wrote:
On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter Palmers wrote:
I guess you will agree if I state that it would have been better if you
performed this though experiment while the API was still in a volatile
stage. But that observation doesn't help us, so let's not go
On Wed, 2008-01-16 at 17:41 +0100, Fons Adriaensen wrote:
Well, IIRC, I did raise my voice then, saying it was a pity
that it was actually MIDI that was being implemented, with all
its limitations, and not some extended format that midi could
be trivially and losslessly translated to, using
27 matches
Mail list logo
