Arnold Krille 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
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
Jens M Andreasen wrote:
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
On Tuesday 15 March 2005 08:58, Olivier Guilyardi wrote:
Arnold Krille 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
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
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
Jens M Andreasen wrote:
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
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
Paul Davis wrote:
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
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
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
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
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
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
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
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
Wouldn't it be better to put the structures in shared memory and
not use any locking / signalling at all?
Melanie
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
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,
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
20 matches
Mail list logo
