20 Dec
2011
20 Dec
'11
2:10 a.m.
Hi, I'm sure others have tackled this and have some wisdom to share. My
project is principally a monosynth step sequencer. This is nice an simple
to do in real time because resolution is very limited and there can be only
one note per track. So step sequenced note data is stored in simple
multi-dimensional arrays, making reading and writing very easy, and
messaging simple between audio and gui threads.
However, I would like to add the ability for the user to send a message and
have it get executed later, where later gets figured out by the engine ( ie
on the top of the next 8 bar phrase ). To do this, I need some way of
storing deferred events and having the engine check on each step whether
there were any deferred events stored for 'now'. I can think of a few ways
to do this, and all of them raise red flags for a real time thread.
- I could use a hash table, hashed by time, with a linked list of all the
events for that time. The engine looks up the current time and gets all the
events. I don't know much about hashing so I'd prob just use Boost, is that
a bad idea?
- I could make a linked list of all deferred events and iterate through
them checking if time is now. There wouldn't be any hashing, but maybe this
list would be really big.
Anyone have any suggestions for how to safely do the above or some better
alternative?
thanks!
iain
20 Dec
20 Dec
2:33 a.m.
On Mon, Dec 19, 2011 at 5:10 PM, Iain Duncan <iainduncanlists(a)gmail.com>wrote;wrote:
Anyone have any suggestions for how to safely do the
above or some better
alternative?
I will state my current implementation of such a feature, and let you
decided if its good / bad / ugly :D
enum TrackState {
TRACK_STATE_NORMAL,
TRACK_STATE_EVENT_QUEUED,
TRACK_STATE_EVENT_NOW,
};
process()
{
if ( state == TRACK_STATE_EVENT_QUEUED && time == topOfTrack )
processQueuedEvent();
else if ( state == TRACK_STATE_EVENT_NOW )
processNowEvent();
// process your MIDI output or whatever your doing..
}
I'm storing all the "events" in a ringbuffer that another thread can write
to, so say GUI stuff all gets updated trough "Event::setX()" style
functions, and then they're read "raw" on the other side (public member
variables..) its not strictly OOP, but I don't want to write the 30+
functions & structs* to pass back exactly what is expected every time :)
I think its a pretty OK way of going, each track will have a "TrackState"
variable, and that tells you everything you need about the track. Of course
if you want to have multiple things like playing - paused - relocating, as
well as normal - queued - now, then you should convert them to bitfields,
or separate enums to keep yourself sane...
I've just the one, but my "BufferAudioSource" doesn't have that many
states
that can be active at the same time, so I've just kept it like above.
Simple :)
HTH, -Harry
PS: Re RT-ness, enum's are just ints, so its a RT safe & cheap.
PSS: Perhaps you could elaborate on what these "Events" could be, like just
a single event per track, or are we talking hundreds?
3:53 a.m.
I guess what I'm really interested in is how others have anchored events to
a timeline. Another way of doing it would be to trade ram and a bit of
accuracy for speed of execution by having an array that is PartsPerQuarter
* max_length_in_quarters long, and use that array to hold events, allowing
more than one event to be anchored to the same place by using a linked
list.
Feedback welcome. =-/
iain
4:49 a.m.
On Mon, Dec 19, 2011 at 8:10 PM, Iain Duncan <iainduncanlists(a)gmail.com> wrote:
However, I would like to add the ability for the user
to send a message and
have it get executed later, where later gets figured out by the engine ( ie
on the top of the next 8 bar phrase ). To do this, I need some way of
storing deferred events and having the engine check on each step whether
there were any deferred events stored for 'now'. I can think of a few ways
to do this, and all of them raise red flags for a real time thread.
1) don't allow out-of-order queuing
2) just use a FIFO (i.e. ye olde single-reader/single-writer lock free
ringbuffer) to enqueue events between the engine and another thread
(presumably a GUI)
things get more complex if you insist on allowing out-of-order queuing
and/or more than one thread is delivering events. but not a lot more.
you can so multi-writer/single-reader FIFO in an RT safe way by
requiring a lock to write, but none to read, which serializes writes
and reduces it to an effectively single-writer/single reader
situation.
8:13 a.m.
Hi,
You might also want to have a look at how Supercollider does it:
http://www.supercolliderbook.net/
Look below for the chapter by Ross Bencina.
Cheers,
Andrés
On Tue, Dec 20, 2011 at 3:49 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Mon, Dec 19, 2011 at 8:10 PM, Iain Duncan
<iainduncanlists(a)gmail.com> wrote:
However, I would like to add the ability for the
user to send a message and
have it get executed later, where later gets figured out by the engine ( ie
on the top of the next 8 bar phrase ). To do this, I need some way of
storing deferred events and having the engine check on each step whether
there were any deferred events stored for 'now'. I can think of a few ways
to do this, and all of them raise red flags for a real time thread.
1) don't allow out-of-order queuing
2) just use a FIFO (i.e. ye olde single-reader/single-writer lock free
ringbuffer) to enqueue events between the engine and another thread
(presumably a GUI)
things get more complex if you insist on allowing out-of-order queuing
and/or more than one thread is delivering events. but not a lot more.
you can so multi-writer/single-reader FIFO in an RT safe way by
requiring a lock to write, but none to read, which serializes writes
and reduces it to an effectively single-writer/single reader
situation.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev 
2:11 p.m.
[Paul Davis]
On Mon, Dec 19, 2011 at 8:10 PM, Iain Duncan
<iainduncanlists(a)gmail.com> wrote:
Alternatively, out-of-order queuing can be dealt with by sorting the
contents of the FIFO in the consuming thread (since the write position
only ever increases, sorting everything before it is safe). Multiple
writers can be supported locklessly by employing one FIFO per writing
thread (the consuming thread peeks at the contents of all FIFOs before
deciding which event to pop first).
Tim
However, I would like to add the ability for the
user to send a message and
have it get executed later, where later gets figured out by the engine ( ie
on the top of the next 8 bar phrase ). To do this, I need some way of
storing deferred events and having the engine check on each step whether
there were any deferred events stored for 'now'. I can think of a few ways
to do this, and all of them raise red flags for a real time thread.
1) don't allow out-of-order queuing
2) just use a FIFO (i.e. ye olde single-reader/single-writer lock free
ringbuffer) to enqueue events between the engine and another thread
(presumably a GUI)
things get more complex if you insist on allowing out-of-order queuing
and/or more than one thread is delivering events. but not a lot more.
you can so multi-writer/single-reader FIFO in an RT safe way by
requiring a lock to write, but none to read, which serializes writes
and reduces it to an effectively single-writer/single reader
situation.
4:01 p.m.
On Tue, Dec 20, 2011 at 8:24 AM, Tim Goetze <tim(a)quitte.de> wrote:
Alternatively, out-of-order queuing can be dealt with
by sorting the
contents of the FIFO in the consuming thread (since the write position
only ever increases, sorting everything before it is safe).
as long as the length of the FIFO is relatively small, this is true.
sorting is rarely linear though, so you need to be careful if you want
this to scale to absurdly large message queues :)
Multiple
writers can be supported locklessly by employing one FIFO per writing
thread (the consuming thread peeks at the contents of all FIFOs before
deciding which event to pop first).
true, though this is more complex for the reader, and the writers are
rarely under RT constraints which means that the serialization via a
lock doesn't hurt anyone.
21 Dec
21 Dec
1:50 a.m.
Either I'm misunderstanding the answers, or I have not done a good job of
asking my question.
In more detail, here's what I'm curious about how people have done:
The sequencer has a clock, it nows what time 'now' is in bars:beats:ticks.
Events are stored somehow, encoded to a time in bars:beats:ticks. These may
be added on the fly to any time, and the sequencer must be able to hop
around non-linearly in time ( looping, jumping to marks, etc). How does the
sequencer engine find events stored for 'now', quickly enough that we can
be somewhat deterministic about making sure it can get all the events for
any time? ( 'now' may even be different on a track by track basis ).
Does it look up 'now' in some kind of hashed pile of events, where events
are keyed by a time? This makes me worry about hashing algorithms, but
would sure be the easiest to implement.
Is there some kind of master timeline array that events get attached to?
This seems like it would be quick to seek to a point, but use up a lot of
ram for the timeline array and I'm not sure how one would handle unlimited
length timelines.
I'd not clear how the above have to do with communicating between threads
using ringbuffers, I'm just talking about how the audio call back stores
events for a given time and then finds them quickly at that time. But maybe
I'm totally missing something here.
Would love to hear in pseudo code how others have tackled storing and
finding events in time.
thanks!
Iain
2:04 a.m.
I've created a very basic MIDI sequence a while ago, and the following is
how I done it:
-"Time" is kept track of using JACK frames, and a BPM. This tells you how
many beats (from frame 0) you've played, and what "percentage" or part of
beat your in.
-"EventClip" objects have a big vector of "EventClipElement"s, which
represent events like NOTE_ON, NOTE_OFF, CC_CHANGE, etc.
-Process() gets Time information: int currentBeat; float currentPercent;
-Check if the "time" just went past the next Event in the clip:
// start code
if ( EventClip->upcomingEvent()->beat == currentBeat )
{
if ( EventClip->nextEvent()->percent <= currentPercent)
{
processEvent(); // write MIDI message in this case
EventClip->goToNextEvent();
}
}
// end code
That's pretty much it, now for the caveat's:
-Vector's are not RT friendly, so use a List, or reserve *plenty* of space
in your vector!
-The EventClip class can be very simple, it only needs a way to quickly
retrieve the *next* event, so having a member pointer to the next
EventClipElement in the vector will make avoid lots of array access.
-If you relocate on the timeline, then you'll have to "search" through the
vector to find the right nextEvent. (ie where currentBeat == beat, but
currentPercent < eventPercent)
Note this was the first time I got a MIDI sequencer running, and there are
probably other ways to do it too... perhaps which provide cleaner code &
better readability...
Keeping an eye on this :D -Harry
12:17 p.m.
[Paul Davis]
There'll be at least the realtime MIDI input thread, and then there
are events generated from audio streams that have to be dispatched in
a lockfree code path. (Of course, none of this is much of a concern
if you do all your realtime work in a jack audio processing callback.)
Tim
On Tue, Dec 20, 2011 at 8:24 AM, Tim Goetze
<tim(a)quitte.de> wrote:
Yes, and fortunately commonly occurring events from MIDI-sourced
tracks are relatively sparse. If these events are only enqueued in
bursts a handful of times per second the sorting overhead is quite
small, and reduced further if sorting only occurs when the consuming
thread detects write pointer movement on the FIFO. (Since there's a
certain contention for the track lock between recording, playback and
editing, hard realtime access to the track contents seems all but out
of the question anyway.)
Alternatively, out-of-order queuing can be dealt
with by sorting the
contents of the FIFO in the consuming thread (since the write position
only ever increases, sorting everything before it is safe).
as long as the length of the FIFO is relatively small, this is true.
sorting is rarely linear though, so you need to be careful if you want
this to scale to absurdly large message queues :) Multiple
writers can be supported locklessly by employing one FIFO per writing
thread (the consuming thread peeks at the contents of all FIFOs before
deciding which event to pop first).
true, though this is more complex for the reader, and the writers are
rarely under RT constraints which means that the serialization via a
lock doesn't hurt anyone.
2:44 p.m.
On Wed, Dec 21, 2011 at 6:30 AM, Tim Goetze <tim(a)quitte.de> wrote:
not if you use JACK MIDI, which will take care of all that for you.
then you just have the opposite problem: how to get any MIDI data
needed by the non-RT components of your app out of the RT JACK
thread(s).
[Paul Davis]
true, though
this is more complex for the reader, and the writers are
rarely under RT constraints which means that the serialization via a
lock doesn't hurt anyone.
There'll be at least the realtime MIDI input thread, and then there
4734
days inactive
4735
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
Andres Cabrera -
Harry van Haaren -
Iain Duncan -
Paul Davis -
Tim Goetze