13 Mar
2005
13 Mar
'05
5:12 p.m.
Hi,
This may be a general IPC question, but I feel lost so I thought you may help me
as you did in the past for some other issue.
In Jackbeat (written in C), I have the gui running in one thread (the gtk main
loop) and jack in its thread. Currently, when tracks get updated, the main loop
sends a message to the jack thread, and then waits for an acknowledgement. I
currently use syscalls (message queues) for these messages, but that's not my
point (I'll turn that later into syscall-free fifos).
Waiting for an ack from the jack thread has a consequence : it locks the gui for
a brief moment, which seems to drive my spin buttons mad : when clicked they
will sometimes step the value by 1, sometimes 2, etc...
Additionally, I think the gui should never lock, for confort. So I though about
a "shadow" data structure. It would act as a intermediary area between my two
threads.
The jack thread runs into what I call a "sequence". When processing sound it
relies on a structure called sequence_t. I'm about to add a new member to this
structure, called shadow, which would actually be of the sequence_t type itself.
This nested shadow structure would never be accessed by the jack thread. The
public sequence functions could safely update this shadow, so that the gui can
read from it anytime without any latency.
Message queues would still be used to let the jack thread update itself the
"real" sequence. This is where would reside some latency : waiting for the jack
thread to get in sync. But the gui would never lock.
I'm not sure this is a very clear description, but do you have any advice about
this kind of issue ? Is my idea a good one ?
Cheers
--
og
13 Mar
13 Mar
5:36 p.m.
Wouldn't it be better to put the structures in shared memory and
not use any locking / signalling at all?
Melanie
6:01 p.m.
Melanie wrote:
Wouldn't it be better to put the structures in
shared memory and not use
any locking / signalling at all?
There's a need for syncing threads. It is not possible to touch the
tracks/bpm/etc directly while jack's process callback is in the middle of its
work. Some actions do not require any ack from the jack thread, like setting the
bpm, but when it comes to reallocating data (for ex: adding/removing a track)
that is currently needed.
However, all actions (with or without any ack) currently require using some sort
of message queue or fifo, and I don't see how and why this would change.
--
og
7:13 p.m.
In Jackbeat (written in C), I have the gui running in
one thread (the gtk main
loop) and jack in its thread. Currently, when tracks get updated, the main loo
p
sends a message to the jack thread, and then waits for an acknowledgement. I
currently use syscalls (message queues) for these messages, but that's not my
point (I'll turn that later into syscall-free fifos).
Waiting for an ack from the jack thread has a consequence : it locks the gui f
or
a brief moment, which seems to drive my spin buttons mad : when clicked they
will sometimes step the value by 1, sometimes 2, etc...
don't wait in the GUI. what you need to do is to hook a notification
mechanism from the RT thread into the main event loop of the
GUI. having the RT thread write a byte to a FIFO or raise/lower a
semaphore are the two best generally available ways of having it
notify the GUI that something has happened that it needs to know about.
many programs use this mechanism.
Message queues would still be used to let the jack
thread update itself the
"real" sequence. This is where would reside some latency : waiting for the jack
thread to get in sync. But the gui would never lock.
forget the idea of "sync". your GUI has no way to update more than
about 60-80 times a second anyway (because of the monitor refresh
frequency. your goal is to make sure that the GUI reflects the state
of the model/backend ASAP after the model/backend changes.
--p
14 Mar
14 Mar
9:17 a.m.
Paul Davis wrote:
Here's what happens when resizing the workspace (adding/removing tracks or
beats, etc...) :
- gui_sequence_resized() is called by gtk
- gui_sequence_resized() calls sequence_resize()
- sequence_resize() allocate some new stuff, and waits for the jack thread to sync
- then gui_sequence_resized() calls gui_refresh()
- gui_refresh() calls gui_draw_tracks() which itself queries the sequence in
various manners : how many tracks do you have ? what beats are on/off ? etc...
The point is because gui_draw_tracks() calls such functions as
sequence_get_tracks_num() which rely on the sequence data to be up to date,
there's a need for the jack thread to sync. That is because it's the job of the
jack thread to update the actual sequence data, because it's the one which knows
when it can do that safely.
Do you mean that I should avoid letting the gui query the sequence directly
about tracks number, beats status, etc ? And replace that by an event/callback
paradigm ? The sequence would raise signals for the gui to update itself, in the
same manner as user actions raise signals ?
If that is the case I think I'd go with my g_timeout reading informations from a
fifo and then calling the appropriate "callback" gui functions. Or maybe
there's
a way to use a general g_source in a thread-safe manner.
--
og
don't wait in the GUI. what you need to do is to
hook a notification
mechanism from the RT thread into the main event loop of the
GUI. having the RT thread write a byte to a FIFO or raise/lower a
semaphore are the two best generally available ways of having it
notify the GUI that something has happened that it needs to know about.
many programs use this mechanism.
I need to investigate that. Do you know of some simple application (I think I'd
get lost into Ardour) demonstrating your point ?
Message queues
would still be used to let the jack thread update itself the
"real" sequence. This is where would reside some latency : waiting for the jack
thread to get in sync. But the gui would never lock.
forget the idea of "sync". your GUI has no way to update more than
about 60-80 times a second anyway (because of the monitor refresh
frequency. your goal is to make sure that the GUI reflects the state
of the model/backend ASAP after the model/backend changes. 
13 Mar
13 Mar
8:58 p.m.
On Sun, 2005-03-13 at 22:12 +0100, Olivier Guilyardi wrote:
Hi,
...
I'm not sure this is a very clear description, but do you have any advice about
this kind of issue ? Is my idea a good one ?
Looking at your screenshot and reading the labels I wonder why the UI is
so concerned about what jack is doing. I would have thought jack_run
will do whatever the UI appears like, no? The exception being time
information/sample count needed to update blinking-lights and
measure-count.
g_timeout_add ( 50,
my_time_function,
(void*)some_data );
For pressing buttons I see no reason why you should not just go ahead
and update the structure that jack_run can see. Assuming this is a
simple integer update.
Say you need to load files, malloc and whatnot for a new track. Fine, do
all that first and then let jack_run insert the new track into the main
structure before doing the actual run.
if(p){ // we have a new track to insert
...
p = NULL; // notify it is done
}
if(q){ // we should delete one track
...
q = NULL;
}
// start of jack_run
...
--
(
)
c[] // Jens M Andreasen
14 Mar
14 Mar
8:43 a.m.
Jens M Andreasen wrote:
Looking at your screenshot and reading the labels I
wonder why the UI is
so concerned about what jack is doing. I would have thought jack_run
will do whatever the UI appears like, no? The exception being time
information/sample count needed to update blinking-lights and
measure-count.
g_timeout_add ( 50,
my_time_function,
(void*)some_data );
Yeah, that's what I'm using for the blinking lights.
For pressing buttons I see no reason why you should
not just go ahead
and update the structure that jack_run can see. Assuming this is a
simple integer update.
Right, for pressing beats buttons, there's no need to lock anything.
Say you need to load files, malloc and whatnot for a
new track. Fine, do
all that first and then let jack_run insert the new track into the main
structure before doing the actual run.
if(p){ // we have a new track to insert
...
p = NULL; // notify it is done
}
if(q){ // we should delete one track
...
q = NULL;
}
// start of jack_run
...
You quite simplify things (you can add tracks but also increase beats number,
etc...) but you're not so far of what I actually do. The point is that right
after calling sequence_resize() (which does a similar thing to what you
describe), the gui automatically refreshes itself (redrawing all of the tracks)
and for this purpose queries the sequence to know what it has do draw.
But "right after" resizing the sequence, the jack thread is likely no to have
yet received messages and updated the actual sequence data so that the gui is
going to read out-of-date or in-the-process-of-getting-updated informations
about tracks.
This is where my shadow would play its role. By getting updated "right after" a
such (currently locking) function as sequence_rezize(), the gui could read from
the sequence very fast. This shadow is somehow fake : it has no consequence on
the sound, it is here to simulate zero-latency so that the gui can run as fast
as it wants. The "real" sequence data would then get transparently updated in
the background, by the jack thread.
I'm now starting to think that this shadow should be part of the gui data. So
that the gui update itself directly, signalling the sequence to change but never
querying the sequence to know what actually happens underground. The gui would
be more self-contained.
Or the gui could get notified by the sequence as Paul explains.
--
og
11:20 a.m.
On Mon, 2005-03-14 at 13:43 +0100, Olivier Guilyardi wrote:
I'm now starting to think that this shadow should be part of the gui data. So
that the gui update itself directly, signalling the sequence to change but never
querying the sequence to know what actually happens underground. The gui would
be more self-contained.
Isn't the GUI already a kind of "shadow data"?
gtk_toggle_button_get_active ()
--------------------------------
Returns TRUE if the toggle button is pressed in
and FALSE if it is raised.
Or the gui could get notified by the sequence as Paul
explains.
I also think you can relax your speed expectations slightly. With jack
running say 64 samples each time around, it will have done its thing 10
times before the next monitor refresh.
--
og
--
(
)
c[] // Jens M Andreasen
12:34 p.m.
Jens M Andreasen wrote:
Isn't the GUI already a kind of "shadow
data"?
gtk_toggle_button_get_active ()
--------------------------------
Returns TRUE if the toggle button is pressed in
and FALSE if it is raised.
Indeed. You exactly got what I mean. It then becomes more a design issue : the
gui, based on gtk, is "shadow-capable" but I'm not using this ability.
Additionally, redesigning things so that the gui properly "shadows" the sequence
would oblige me to heavily optimize things. When adding a single track I
currently destroy the whole workspace and query the sequence to so that the gui
can redraw the whole thing, recreating all widgets.
By redesigning the gui, I would keep many widgets as they are and only create
some new ones, or destroy a few... This is very important, when you have a big
workspace (ie: 1k beats, 16 tracks), because things then get very slow the way I
currently do.
I did think about this, but it required coding a lot of small functions for a
variety specialized routines, and I would also need to change the way files get
loaded (this last point is the main reason why I wanted to put the shadow within
the sequence itself). Anyway, although it requires some work, I think this is
the way to go.
>Or the gui could get notified by the sequence as
Paul explains.
I hesitate here : would a such sequence-to-gui notification design be more
souple/maintainable than a "shadowing" gui, for future, unplaned features ?
I guess the two paradigms could coexist, if I ever need the RT thread to send
signals to the gui...
I also think you can relax your speed expectations
slightly. With jack
running say 64 samples each time around, it will have done its thing 10
times before the next monitor refresh.
My jackd manpage states that the default frames/period setting is 1024, which
means that for a frame rate of 44100 Hz, I'm around 44 periods by second, which
is less than a monitor refresh. And what if some user needs to set that up to
4096 frames/period or more ?
--
og
3:39 p.m.
On Monday 14 March 2005 17:34, Olivier Guilyardi wrote:
My jackd manpage states that the default frames/period
setting is 1024,
which means that for a frame rate of 44100 Hz, I'm around 44 periods by
second, which is less than a monitor refresh. And what if some user needs
to set that up to 4096 frames/period or more ?
Wouldn't this mean that his system is very slow or at least needs such slow
settings to run stable?
Which in turn means, he is used to slow reactions of the system / the gui...
And even if the gui reacts at once to his changes, this would confuse him,
since the sound of his changes will be noticable later...
Arnold
BTW: I myself use slow, stable settings sometimes for mastering where I don't
need input or fast reactions...
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
15 Mar
15 Mar
3:58 a.m.
Arnold Krille wrote:
I have a habit of deciding wether software is good or not according to its
ability to run "fast" on slow systems, take for example the Gimp... I'm
everyday
amazed by the Gimp.
And my first tests with a non-locking GUI greatly improve responsiveness on my
Duron 700mhz system. Additionally, if 1024 frames/period is the default setting,
that means it's the setting newbies will use, like musicians I know who consider
the switch from Windows and who don't have a clue what jack is. They'll just get
rpms or the like.
With 1024 frames/period I expect a 64bits quad-cpu system to show GUI latency if
I continue to lock (waiting for an ack from the RT thread) the way I do. In this
case, even the newbie will laugh.
--
og
My jackd
manpage states that the default frames/period setting is 1024,
which means that for a frame rate of 44100 Hz, I'm around 44 periods by
second, which is less than a monitor refresh. And what if some user needs
to set that up to 4096 frames/period or more ?
Wouldn't this mean that his system is very slow or at least needs such slow
settings to run stable?
Which in turn means, he is used to slow reactions of the system / the gui...
And even if the gui reacts at once to his changes, this would confuse him,
since the sound of his changes will be noticable later...
6:41 a.m.
On Tuesday 15 March 2005 08:58, Olivier Guilyardi wrote:
Arnold Krille wrote:
I have a
habit of deciding wether software is good or not according to its
ability to run "fast" on slow systems, take for example the Gimp... I'm
everyday amazed by the Gimp.
And my first tests with a non-locking GUI greatly improve responsiveness on
my Duron 700mhz system. Additionally, if 1024 frames/period is the default
setting, that means it's the setting newbies will use, like musicians I
know who consider the switch from Windows and who don't have a clue what
jack is. They'll just get rpms or the like.
With 1024 frames/period I expect a 64bits quad-cpu system to show GUI
latency if I continue to lock (waiting for an ack from the RT thread) the
way I do. In this case, even the newbie will laugh.
So I think we should distinguish between locked gui and a non-locked gui
representing the real state as soon as the state is reached. Which might be a
time after the user clicked the button.
We once encountered such things in the aRts-GUI: One of our tries we did set
the volume from the mouseclick in the volumebar but did the repainting of the
volumebar after the rest of aRts informed us about the volumechange. Which
led to some slow responses of the fader...
Maybe with such big changes as deleting channels/track/whatsoever you should
recreate/update the gui after the changes are made in the engine (so after
they have an hearable effect). But to not confuse the user because nothing
changes, perhaps you could gray-out the relevant parts in the time between
starting the action and changing the gui.
Which would mean that you have a non-locked gui representing the real state of
the engine...
Did I make may thoughts clear? Its before my first coffee/tea...
Arnold
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
My jackd
manpage states that the default frames/period setting is 1024,
which means that for a frame rate of 44100 Hz, I'm around 44 periods by
second, which is less than a monitor refresh. And what if some user needs
to set that up to 4096 frames/period or more ?
Wouldn't this mean that his
system is very slow or at least needs such
slow settings to run stable?
Which in turn means, he is used to slow reactions of the system / the
gui... And even if the gui reacts at once to his changes, this would
confuse him, since the sound of his changes will be noticable later...
11:45 a.m.
Arnold Krille wrote:
So I think we should distinguish between locked gui
and a non-locked gui
representing the real state as soon as the state is reached. Which might be a
time after the user clicked the button.
We once encountered such things in the aRts-GUI: One of our tries we did set
the volume from the mouseclick in the volumebar but did the repainting of the
volumebar after the rest of aRts informed us about the volumechange. Which
led to some slow responses of the fader...
Maybe with such big changes as deleting channels/track/whatsoever you should
recreate/update the gui after the changes are made in the engine (so after
they have an hearable effect). But to not confuse the user because nothing
changes, perhaps you could gray-out the relevant parts in the time between
starting the action and changing the gui.
Which would mean that you have a non-locked gui representing the real state of
the engine...
Did I make may thoughts clear? Its before my first coffee/tea...
That is very clear to me, indeed. What's your coffee brand ? ;-)
Your thoughts are interesting because I was hesitating about this. I began to
code some "blind non-locking gui", that is : it does not wait for the RT thread
to sync, but it doesn't ensure if the changes really took place or not.
My method is not supposed to confuse the user. But there is, and there will bugs
in the underlying data processing, and for sure my blindish method will make
debugging harder, since the gui will look just fine, while the sound is getting
broken. My previous locking method really helped me in debugging, since the gui
always showed what's under and what's not.
You meet Paul Davis about his RT-thread-to-gui notification method, using a fifo
or similar. I thought this was a bit of a complicate thing, and graying some
tracks out while they get processed will increase the work needed. But, I
believe you're right, about "representing the real state of the engine".
If I understand you correctly, some part of the GUI could act "blindly", but big
changes should require an acknoledgement from the RT thread. Actually this is
exactly what Jackbeat 0.4.0 does, except that it does lock on big changes.
I'm wondering if I shouldn't stay with my current locking implementation until I
get myself clearer about all of that. Is there any good C sources (I'm not
really into C++) you'd advise me to look at ?
--
og
14 Mar
14 Mar
3:53 p.m.
On Mon, 2005-03-14 at 17:34 +0100, Olivier Guilyardi wrote:
My jackd manpage states that the default frames/period
setting is 1024, which
means that for a frame rate of 44100 Hz, I'm around 44 periods by second, which
is less than a monitor refresh. And what if some user needs to set that up to
4096 frames/period or more ?
I'm confused as to why you use the default frames/period setting (1024)
but not the default samplerate (48000) for your calculations. 48000 is
much easier to work with than 44100 for the purposes of these types of
calculations.
Lee
15 Mar
15 Mar
4:03 a.m.
Lee Revell wrote:
I'm confused as to why you use the default
frames/period setting (1024)
but not the default samplerate (48000) for your calculations. 48000 is
much easier to work with than 44100 for the purposes of these types of
calculations.
Wow, I forgot that. I've been running jack at 44100hz for a long time... Hell,
I'm not doing _any_ rate conversion. That means that with default settings, it
will screw things up. I have to consider playing with Secret Rabbit Code soon.
Thanks
--
og
14 Mar
14 Mar
4:01 p.m.
On Mon, 2005-03-14 at 17:34 +0100, Olivier Guilyardi wrote:
Jens M Andreasen wrote:
> I also think you can relax your speed
expectations slightly ...
My jackd manpage states that the default frames/period
setting is 1024, which
means that for a frame rate of 44100 Hz, I'm around 44 periods by second, which
is less than a monitor refresh. And what if some user needs to set that up to
4096 frames/period or more ?
Well ... Currently I work with 32 samples at 48K, which has the
advantage of being RT playable in a Detroit clavinet funky style. The
default setting is perhaps intended for mp3 players and such?
--
(
)
c[] // Jens M Andreasen
6:29 p.m.
On Mon, 2005-03-14 at 17:34 +0100, Olivier Guilyardi wrote:
Additionally, redesigning things so that the gui
properly "shadows" the sequence
would oblige me to heavily optimize things. When adding a single track I
currently destroy the whole workspace and query the sequence to so that the gui
can redraw the whole thing, recreating all widgets.
Inserting the new widgets and having them propagate up thru the layout
engine in order to be redrawn is probably expensive whatever way you do
it.
Scrapping the underlying structure (is "workspace" equal to
"sequence_t"
here?) sounds a bit overdramatic though. I would instead like yo
envision something like blocks of 32 tracks × 32 beats that can be
extended vertically or horisontally as in:
[ ]->[ ]->
or:
[ ]
|
v
[ ]
|
V
or both ways:
[ ]->[ ]->
|
v
[ ]->[ ]->
|
v
In this fashion you could most of the time get away with adjusting
max_track and/or max_beat. A deleted track will stop sounding when you
hear the click from the mouse-button (although it may take a little
longer before the UI has rearranged itself.)
By redesigning the gui, I would keep many widgets as
they are and only create
some new ones, or destroy a few... This is very important, when you have a big
workspace (ie: 1k beats, 16 tracks), because things then get very slow the way I
currently do.
Yeah .. I can imagine that one to be slow :) OTOH, the whole concept is
pretty much broken by then ...
I did think about this, but it required coding a lot of small functions for a
variety specialized routines, and I would also need to change the way files get
loaded (this last point is the main reason why I wanted to put the shadow within
the sequence itself). Anyway, although it requires some work, I think this is
the way to go.
Waiting for IO is a classic way of having the UI get stuck and
irresponsive. Therefore the nice people at gtk.org made this writeup:
Monitoring IO
-------------
http://gtk.org/tutorial/sec-monitoringio.html
--
(
)
c[] // Jens M Andreasen
15 Mar
15 Mar
4:36 a.m.
Jens M Andreasen wrote:
The thing is I personnally used such high number of beats, but it is not a good
idea. I want to implement "sequence nesting" since the first lines of Jackbeat,
which would help avoiding such big sequences : you could nest a sequence into an
other, that means assign a sequence to a track as you assign a sample.
With a few sequences on your screen you could then achieve both long melodies
and precise rythms. But I was unsuccesul with my first attempt to code a such
sequence "graph" (it is not just a sequence "playlist", you would be
able to
cascade sequences).
On Mon, 2005-03-14 at 17:34 +0100, Olivier Guilyardi
wrote:
Inserting the new widgets and having them propagate up thru the layout
engine in order to be redrawn is probably expensive whatever way you do
it.
Yeah, I'd have to reparent widgets, destroy a gtk table, and show the whole
thing up again. I guess it wouldn't be such an optimization. Needs testing though.
Of couse with a gtk DrawingArea, I could optimize the drawing at low-level, but
I don't think I'll go that way. I like these gtk buttons, altough inspired by
Aube's drummmachine, it's Jackbeat's touch ;-) Especially I like the way they
scale : recoding that kind of dynamics within a DrawingArea would be much work.
Scrapping the underlying structure (is
"workspace" equal to "sequence_t"
here?) sounds a bit overdramatic though. I would instead like yo
envision something like blocks of 32 tracks × 32 beats that can be
extended vertically or horisontally as in:
No I'm not scrapping the whole sequence_t structure when resizing the workspace
(=tracks/beats/measure length) only the sequence_t->tracks member. This indeed
could be optimized by playing with pointers, but I believe the bottle-neck is
drawing widgets not resizing the actual underlying tracks data.
In this fashion you could most of the time get away
with adjusting
max_track and/or max_beat. A deleted track will stop sounding when you
hear the click from the mouse-button (although it may take a little
longer before the UI has rearranged itself.)
Well, vertically, for tracks, it makes sense to use say blocks of 8. But for
beats this is not that useful.
By redesigning
the gui, I would keep many widgets as they are and only create
some new ones, or destroy a few... This is very important, when you have a big
workspace (ie: 1k beats, 16 tracks), because things then get very slow the way I
currently do.
Yeah .. I can imagine that one to be slow :) OTOH, the whole concept is
pretty much broken by then ... Waiting for IO is a classic way of having the UI get
stuck and
irresponsive. Therefore the nice people at gtk.org made this writeup:
Monitoring IO
-------------
http://gtk.org/tutorial/sec-monitoringio.html
I'm not sure what you see this for : receiving messages from the RT thread
trough a named pipe, or reading from song files ? In the first case, that
gdk_input_add() could indeed be useful, in order to implement the RT-to-mainloop
notifications Paul talked about.
Thanks
--
og
6:54 a.m.
On Tue, 2005-03-15 at 09:36 +0100, Olivier Guilyardi wrote:
Yeah, I'd have to reparent widgets, destroy a gtk
table, and show the whole
thing up again. I guess it wouldn't be such an optimization. Needs testing though.
Nah, no need to destroy ... a gtk_table_resize () is more like it.
To move things around then? Perhaps gtk_table_attach () will do, or
perhaps you'd have to move one step up to the parent class:
gtk_container_remove (table,widget)
http://www.gtk.org/api/2.6/gtk/GtkContainer.html#gtk-container-remove
BTW: I think jack has left the building by now ...
--
(
)
c[] // Jens M Andreasen
11:55 a.m.
Jens M Andreasen wrote:
On Tue, 2005-03-15 at 09:36 +0100, Olivier Guilyardi
wrote:
Yeah I saw that, but that was at the time I was adding a new feature that allows
to remove a specific track, so that I needed to move all subsequent tracks one
level above. I then thought it was unusable in my case, dreaming about some
spreahsheet-like gtk_table_insert_row(), etc...
But you're right, gtk_table_resize() would be useful in many cases.
Yeah, I'd have to reparent widgets, destroy a
gtk table, and show the whole
thing up again. I guess it wouldn't be such an optimization. Needs testing though.
Nah, no need to destroy ... a gtk_table_resize () is more like it. To move things around then? Perhaps gtk_table_attach
() will do, or
perhaps you'd have to move one step up to the parent class:
gtk_container_remove (table,widget)
http://www.gtk.org/api/2.6/gtk/GtkContainer.html#gtk-container-remove
BTW: I think jack has left the building by now ...
Nah, he's on the roof sleeping in the sun. He should be back soon ;-) But I
really feel like my gtk knowledge is getting to its limits. I need to consider
that side of the problem seriously.
Thanks
--
og
4:43 a.m.
Jens M Andreasen wrote:
In this fashion you could most of the time get away
with adjusting
max_track and/or max_beat. A deleted track will stop sounding when you
hear the click from the mouse-button (although it may take a little
longer before the UI has rearranged itself.)
Actually I currently lock tracks which are to be removed prior to anything else.
So that you can be sure that it stops sounding ASAP. My problem is the way the
GUI stops responding for a short while.
--
og
7221
days inactive
7223
days old
linux-audio-dev@lists.linuxaudio.org
20 comments
6 participants
participants (6)
-
Arnold Krille -
Jens M Andreasen -
Lee Revell -
Melanie -
Olivier Guilyardi -
Paul Davis