24 Dec
2005
24 Dec
'05
12:36 p.m.
Hi everyone,
I'm getting ready to release a new version of WhySynth. If
you have saved any good WhySynth (or Xsynth-DSSI) patch
presets, and want to be immortalized via their inclusion in the
the new WhySynth default patch set, please email them to me.
Thanks,
-Sean
25 Dec
25 Dec
4:10 a.m.
I don't know if this patch belongs in a default patch set. However, I
thought you might be interested in checking out my use of whysynth. I
use the following patch along with the following diff to dssp_synth.c to
sort of emulate my juno 106. A Doepfer Pocket Fader provides the 16
sliders. This seems to work very well. The only think that I'm not sure
if is possible or how to accomplish is to have a single CC controle
multiple synthesis parameters. A single case of this can be accomplished
with the ModMix. < feature request ;) > More ModMixes would be great!
</feature request ;) > Anyway... Thanks for Whysynth. Very cool.
-Garett
# WhySynth patch
WhySynth patch format 0 begin
name GSynth
oscY 1 2 0 -12 0 1 0 0 0 0 0 18 0 0 0
oscY 2 1 2 0 0 0 0 0 0.492026 6 0.149838 18 0 0 0
oscY 3 1 1 0 0 0 0.00362681 0 0 0 0 18 0 0 0
oscY 4 0 24 0 0 0 -0.00030387 0 0 0 0 0 0 0 0
vcfY 1 2 0 50 22 1 0 0
vcfY 2 2 1 3.55629 0 0 0 0
mix 0 0 0 0 0.984671 0.5 1.02186 0.5
volume 0.35
effects 0 0 0 0 0 0 0 0
glide 0.984375
bend 2
lfoY g 0.101461 0 0 0 0
lfoY v 0.05 0 0.1 0 0
lfoY m 0.05 0 0.1 0 0
mlfo 120.296 0
egY o 1 3 0.0119657 1 3 0.1 1 3 6.35257 1 3 0.0159149 0.196778 0 0 0 0
egY 1 0 3 0.1 1 3 0.1 1 3 0.1 1 3 0.0250322 0 0 0 0 0
egY 2 0 3 0.1 1 3 0.1 1 3 0.1 1 3 0.2 0 0 0 0 0
egY 3 0 3 0.1 1 3 0.1 1 3 0.1 1 3 0.2 0 0 0 0 0
egY 4 0 3 0.1 1 3 0.1 1 3 0.1 1 3 0.2 0 0 0 0 0
modmix 0 5 0 17 0
WhySynth patch end
627a628
//modified by garett
631a633,668
case Y_PORT_OSC1_LEVEL_A:
return DSSI_CC(0x30);
case Y_PORT_OSC2_LEVEL_A:
return DSSI_CC(0x32);
case Y_PORT_OSC2_MPARAM2:
return DSSI_CC(0x33);
case Y_PORT_OSC2_MMOD_AMT:
return DSSI_CC(0x34);
case Y_PORT_OSC3_LEVEL_A:
return DSSI_CC(0x31);
//case amp mod source amount for all OSC:
// return DSSI_CC(0x35);
//case frequency for all OSC
// return DSSI_CC(0x36);
case Y_PORT_VCF1_FREQUENCY:
return DSSI_CC(0x37);
//case Y_PORT_VCF1_FREQ_MOD_AMT:
// return DSSI_CC(0x37);
case Y_PORT_VCF1_QRES:
return DSSI_CC(0x38);
//case Y_PORT_VCF1_MPARAM:
// return DSSI_CC(0x39);
case Y_PORT_GLFO_FREQUENCY:
return DSSI_CC(0x3b);
case Y_PORT_EG1_TIME1:
return DSSI_CC(0x3c);
case Y_PORT_EG1_TIME3:
return DSSI_CC(0x3d);
case Y_PORT_EG1_LEVEL3:
return DSSI_CC(0x3e);
case Y_PORT_EG1_TIME4:
return DSSI_CC(0x3f);
case Y_PORT_MODMIX_MOD1_AMT:
return DSSI_CC(0x39);
case Y_PORT_MODMIX_MOD2_AMT:
return DSSI_CC(0x3a);
Sean Bolton wrote:
Hi everyone,
I'm getting ready to release a new version of WhySynth. If
you have saved any good WhySynth (or Xsynth-DSSI) patch
presets, and want to be immortalized via their inclusion in the
the new WhySynth default patch set, please email them to me.
Thanks,
-Sean
4:41 p.m.
Hi Garett,
On Dec 25, 2005, at 12:08 AM, Garett Shulman wrote:
I don't know if this patch belongs in a default
patch set. However, I
thought you might be interested in checking out my use of whysynth. I
use the following patch along with the following diff to dssp_synth.c
to sort of emulate my juno 106. A Doepfer Pocket Fader provides the 16
sliders. This seems to work very well.
Hey, that's cool. I've added the patch (with the oscillator
sends turned up) to the 'development patches' section,
since it's a good starting point for new patches.
The only think that I'm not sure if is possible
or how to accomplish
is to have a single CC controle multiple synthesis parameters. A
single case of this can be accomplished with the ModMix.
Right, presently you can only do this with the ModMix, the
mod wheel, and pressure/aftertouch.
< feature request ;) > More ModMixes would be
great! </feature
request ;) >
Yes, I've wanted that too. I want to keep this next release
backward-compatible with the earlier release, which means
not changing the number of ports, unfortunately.
Actually, what I'd like to do for the '2.x' version is to change
the modulation to be like the Oberheim Matrix synths,
where you have a number of mod source-to-destination
routings, so one mod source can modulate several
destinations, and a destination can be modulated by
several sources. With good MIDI CC mapping capability,
of course!
Anyway... Thanks for Whysynth. Very cool.
-Garett
You're welcome. Thanks for the patch and the feedback,
-Sean
28 Dec
28 Dec
8:06 a.m.
Hi Sean:
A few questions re: your excellent WhySynth :
Can I get multiple instances, each with its own GUI ?
WS seems weird wrt MIDI program change. Am I missing something ?
Sending a change from a sequencer or keyboard doesn't match the default
list of voices. PC 0 selects a sound all right, but it's not the Slow
Strings at position 0 in the default patch list. What is MIDI PC
actually selecting ?
Edits made to a patch don't take effect in realtime, or am I missing
something again ?
Any chance of a multitimbral version ?
I want to create a short demo based on original patches, using only WS
for all the sounds except the drums. So I'll need either multiple
instances or multitimbral capability, or I'll have to sync multiple
tracks. Any other suggestions ?
Best,
dp
8:26 a.m.
On Wed, 2005-12-28 at 07:26 -0500, Dave Phillips wrote:
Hi Sean:
A few questions re: your excellent WhySynth :
Can I get multiple instances, each with its own GUI ?
'jack-dssi-host -2 whysynth.so' should launch two synths with two
separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
synths etc.
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
9:10 a.m.
Lars Luthman wrote:
On Wed, 2005-12-28 at 07:26 -0500, Dave Phillips
wrote:
Thanks Lars, it's just what I needed. :)
Best,
dp
Hi Sean:
A few questions re: your excellent WhySynth :
Can I get multiple instances, each with its own GUI ?
'jack-dssi-host -2 whysynth.so' should launch two synths with two
separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
synths etc.
12:13 p.m.
Lars Luthman wrote:
Okay, that works. Three instances are launched, the first has
Channel 0
in its window titlebar, the next has Channel 1, the last has Channel 2.
However, only Channel 0 is accessable from my sequencer. What's going on
? The channels referred to are MIDI channels, yes ? How can I reach the
other instances ?
Btw, a MIDI activity light would be a nice addition to WhySynth. :)
Best,
dp
'jack-dssi-host -2 whysynth.so' should launch two synths with two
separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
synths etc.
1:45 p.m.
On Wed, 2005-12-28 at 11:33 -0500, Dave Phillips wrote:
Lars Luthman wrote:
Okay, that works. Three instances are launched, the first has
Channel 0
in its window titlebar, the next has Channel 1, the last has Channel 2.
However, only Channel 0 is accessable from my sequencer. What's going on
? The channels referred to are MIDI channels, yes ? How can I reach the
other instances ?
I tried launching two instances of WhySynth with 'jack-dssi-host -2
whysynth.so', and I can access both channels from my keyboard (using
jack-dssi-host from the 2005-09-30 CVS version of DSSI).
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
'jack-dssi-host -2 whysynth.so' should launch two synths with two
separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
synths etc.
10:03 a.m.
On Wednesday 28 December 2005 13:26, Lars Luthman wrote:
On Wed, 2005-12-28 at 07:26 -0500, Dave Phillips
wrote:
It makes multiple instances from the desktop link I created for it as well,
and hadn't thought of trying that before the question was posed. Still
looking for an Icon for it though. Nigel.
Hi Sean:
A few questions re: your excellent WhySynth :
Can I get multiple instances, each with its own GUI ?
'jack-dssi-host -2 whysynth.so' should launch two synths with two
separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
synths etc.
1:36 p.m.
Hi Dave,
On Dec 28, 2005, at 4:26 AM, Dave Phillips wrote:
Okay, that works. Three instances are launched, the first has
Channel
0 in its window titlebar, the next has Channel 1, the last has Channel
2. However, only Channel 0 is accessable from my sequencer. What's
going on ? The channels referred to are MIDI channels, yes ? How can I
reach the other instances ?
What you've done here is start one instance of jack-dssi-host
hosting three instances of the WhySynth plugin. jack-dssi-host
will have one ALSA MIDI port as input, and will split the incoming
MIDI by channel to send to each of the three plugin instances.
So if you can get sound on channel 0, you should be able to get
sound on channels 1 and 2 via the same MIDI connection by just
changing the MIDI channel number. Note that jack-dssi-host will
have created 6 JACK ports for the audio output -- a left and right
out for each plugin instance -- so make sure these are connected
appropriately or you won't hear the output.
If you need three separate ALSA MIDI ports, you can run
'jack-dssi-host whysynth.so' three times, although the ALSA and
MIDI port names get confusing similar when you do so.
HTH. Looking forward to the demo!
-Sean
A few questions re: your excellent WhySynth :
WS seems weird wrt MIDI program change. Am I missing something ?
Sending a change from a sequencer or keyboard doesn't match the
default list of voices. PC 0 selects a sound all right, but it's not
the Slow Strings at position 0 in the default patch list. What is MIDI
PC actually selecting ?
Edits made to a patch don't take effect in realtime, or am I
missing something again ?
Yeah, something's weird -- on my systems, WhySynth responds
as one would expect to program changes coming from external
sources, and patch edits take effect in real time for everything
except the envelopes (where they take effect on the next note
played.)
When you send a PC from an external source, does the high-
lighted patch in the GUI patch list change? Are you using bank
select (which might mean program 128 or 256 of 384 is being
selected instead)?
If you run jack-dssi-host with the '-v' debug switch, do you see
messages like this:
jack-dssi-host: OSC: whysynth/WhySynth/chan00 port 7 = 0.133895
appearing in real time as you edit a patch, or are they delayed?
On Dec 28, 2005, at 8:33 AM, Dave Phillips wrote:
'jack-dssi-host -2 whysynth.so' should launch
two synths with two
separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
synths etc.
2:29 p.m.
Sean Bolton wrote:
Hi Dave,
On Dec 28, 2005, at 4:26 AM, Dave Phillips wrote:
Okay, I retested WS as a single instance and as two (with the -2 option
for jack-dssi-host). With the single instance everything worked as you
describe. However, in the dual-instance scenario the second synth
receives program changes all right (i.e. the highlighted patch changes
in the patch display), but it wasn't receiving note-ons. :( But read on...
A few questions re: your excellent WhySynth :
WS seems weird wrt MIDI program change. Am I missing something ?
Sending a change from a sequencer or keyboard doesn't match the
default list of voices. PC 0 selects a sound all right, but it's not
the Slow Strings at position 0 in the default patch list. What is
MIDI PC actually selecting ?
Edits made to a patch don't take effect in realtime, or am I
missing something again ?
Yeah, something's weird -- on my systems, WhySynth responds
as one would expect to program changes coming from external
sources, and patch edits take effect in real time for everything
except the envelopes (where they take effect on the next note
played.)
When you send a PC from an external source, does the high-
lighted patch in the GUI patch list change? Are you using bank
select (which might mean program 128 or 256 of 384 is being
selected instead)? If you run jack-dssi-host with the '-v' debug
switch, do you see
messages like this:
jack-dssi-host: OSC: whysynth/WhySynth/chan00 port 7 = 0.133895
appearing in real time as you edit a patch, or are they delayed?
They're appearing in realtime. I'm not having the problem now, it was
likely just a doofus user error.
On Dec 28, 2005, at 8:33 AM, Dave Phillips wrote:
Okay, that works. Three instances are launched, the first has Channel
0 in its window titlebar, the next has Channel 1, the last has
Channel 2. However, only Channel 0 is accessable from my sequencer.
What's going on ? The channels referred to are MIDI channels, yes ?
How can I reach the other instances ?
What you've done here is start one instance of jack-dssi-host
hosting three instances of the WhySynth plugin. jack-dssi-host
will have one ALSA MIDI port as input, and will split the incoming
MIDI by channel to send to each of the three plugin instances.
So if you can get sound on channel 0, you should be able to get
sound on channels 1 and 2 via the same MIDI connection by just
changing the MIDI channel number. Note that jack-dssi-host will
have created 6 JACK ports for the audio output -- a left and right
out for each plugin instance -- so make sure these are connected
appropriately or you won't hear the output.
Ah, there's the cuplrit. I reconnected in QJackCtl for simple stereo
output, and I now have multiple instances of WS making sound.
'jack-dssi-host -2 whysynth.so' should launch
two synths with two
separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
synths etc.
HTH. Looking forward to the demo!
Thanks a lot, Sean. On to the music... :)
Best,
dp
5:18 p.m.
Good night,
One creative sound blaster card live of audigy of awe is needed..One
soundfont for the card; it is in the cd of installation of card.
Alsa, Alsa-driver. the program sfxload etc....
See
http://www.google.be/search?hl=fr&q=midi+and+linux&btnG=Rechercher&…
Michel
----- Original Message -----
From: "Dave Phillips" <dlphillips(a)woh.rr.com>
To: "Sean Bolton" <musound(a)jps.net>
Cc: "A list for linux audio users" <linux-audio-user(a)music.columbia.edu>
Sent: Wednesday, December 28, 2005 7:48 PM
Subject: Re: [linux-audio-user] Call for WhySynth presets
Sean Bolton wrote:
Hi Dave,
On Dec 28, 2005, at 4:26 AM, Dave Phillips wrote:
Okay, I retested WS as a single instance and as two (with the -2 option
for jack-dssi-host). With the single instance everything worked as you
describe. However, in the dual-instance scenario the second synth receives
program changes all right (i.e. the highlighted patch changes in the patch
display), but it wasn't receiving note-ons. :( But read on...
A few questions re: your excellent WhySynth :
WS seems weird wrt MIDI program change. Am I missing something ?
Sending a change from a sequencer or keyboard doesn't match the default
list of voices. PC 0 selects a sound all right, but it's not the Slow
Strings at position 0 in the default patch list. What is MIDI PC
actually selecting ?
Edits made to a patch don't take effect in realtime, or am I missing
something again ?
Yeah, something's weird -- on my systems, WhySynth responds
as one would expect to program changes coming from external
sources, and patch edits take effect in real time for everything
except the envelopes (where they take effect on the next note
played.)
When you send a PC from an external source, does the high-
lighted patch in the GUI patch list change? Are you using bank
select (which might mean program 128 or 256 of 384 is being
selected instead)? If you run jack-dssi-host with the '-v'
debug switch, do you see
messages like this:
jack-dssi-host: OSC: whysynth/WhySynth/chan00 port 7 = 0.133895
appearing in real time as you edit a patch, or are they delayed?
They're appearing in realtime. I'm not having the problem now, it was
likely just a doofus user error.
On Dec 28, 2005, at 8:33 AM, Dave Phillips
wrote:
What you've done here is start one instance of jack-dssi-host
hosting three instances of the WhySynth plugin. jack-dssi-host
will have one ALSA MIDI port as input, and will split the incoming
MIDI by channel to send to each of the three plugin instances.
So if you can get sound on channel 0, you should be able to get
sound on channels 1 and 2 via the same MIDI connection by just
changing the MIDI channel number. Note that jack-dssi-host will
have created 6 JACK ports for the audio output -- a left and right
out for each plugin instance -- so make sure these are connected
appropriately or you won't hear the output.
Ah, there's the cuplrit. I reconnected in QJackCtl for simple stereo
output, and I now have multiple instances of WS making sound.
>
'jack-dssi-host -2 whysynth.so' should launch two synths with two
> separate GUIs, 'jack-dssi-host -3 whysynth.so' should launch three
> synths etc.
Okay, that works. Three instances are launched, the first has Channel 0
in its window titlebar, the next has Channel 1, the last has Channel 2.
However, only Channel 0 is accessable from my sequencer. What's going on
? The channels referred to are MIDI channels, yes ? How can I reach the
other instances ? HTH. Looking forward to the demo!
Thanks a lot, Sean. On to the music... :)
Best,
dp
29 Dec
29 Dec
10:34 a.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the same
screen locations as I had them at shutdown from the last execution. Is
this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which is
good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Thanks all,
Rick
2:33 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
On 12/29/05, Rick Wright <riwright(a)vt.edu> wrote:
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the same
screen locations as I had them at shutdown from the last execution. Is
this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which is
good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Thanks all,
Rick
Rick,
QJC does that for me today as long as I have nothing else open on
the desktop.
- Mark
2:49 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the same
screen locations as I had them at shutdown from the last execution.
Is this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which is
good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Thanks all,
Rick
Rick,
In Fluxbox, just right-click on the window title and under Remember you
will find: Workspace, Head, Dimensions, Position, Sticky, Decorations,
Shaded, Layer, and Save on close.
Further, you can have multiple programs accessible under Fluxbox's
tabbed interface open in a single window. With Ardour for example you
can have the Editor and the Mixer open in the same window, and with
focus following cursor (Sloppy Focus or Semi Sloppy Focus) switch
between them with a flick.
Frank
2:56 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the same
screen locations as I had them at shutdown from the last execution. Is
this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which is
good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Window positioning persistence is already featured and is default
behavior, for quite some time. AFAICS its been ever since ;). Problem is
that behavior may vary, with some glitches depending on your particular
WM. It is well known, at least to me, that window positions aren't
remembered very well if you stick to use the WM close button on those
window titles, usually the ones labeled as [X]. OTOH if you use qjackctl
main window control buttons, to toggle child window visibility and to
quit application, all seems to work just fine ;) or so I believe and
been told.
Cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
3:46 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rui Nuno Capela wrote:
Rick Wright wrote:
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not, but
it seems that the windows don't like the presence of other windows (i.e.
an xterm from which to start QJC!) and the most prevalent offender is
the main window. Actually, it seems that upon the first restart of QJC,
the positions are remembered, but without moving any windows, a second
quit/restart results in some windows appearing cascaded from the top
left of the desktop. Window sizes are always remembered.
Can anyone else reproduce this?
Rick
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the same
screen locations as I had them at shutdown from the last execution.
Is this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which
is good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Window positioning persistence is already featured and is default
behavior, for quite some time. AFAICS its been ever since ;). Problem
is that behavior may vary, with some glitches depending on your
particular WM. It is well known, at least to me, that window positions
aren't remembered very well if you stick to use the WM close button on
those window titles, usually the ones labeled as [X]. OTOH if you use
qjackctl main window control buttons, to toggle child window
visibility and to quit application, all seems to work just fine ;) or
so I believe and been told.
3:58 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
On Thu, 2005-12-29 at 14:46 -0500, Rick Wright wrote:
Rui Nuno Capela wrote:
What desktop environment and window manager are you using and which
version?
Lee
Rick Wright wrote:
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not, but
it seems that the windows don't like the presence of other windows (i.e.
an xterm from which to start QJC!) and the most prevalent offender is
the main window. Actually, it seems that upon the first restart of QJC,
the positions are remembered, but without moving any windows, a second
quit/restart results in some windows appearing cascaded from the top
left of the desktop. Window sizes are always remembered.
Can anyone else reproduce this?
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the same
screen locations as I had them at shutdown from the last execution.
Is this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which
is good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Window positioning persistence is already featured and is default
behavior, for quite some time. AFAICS its been ever since ;). Problem
is that behavior may vary, with some glitches depending on your
particular WM. It is well known, at least to me, that window positions
aren't remembered very well if you stick to use the WM close button on
those window titles, usually the ones labeled as [X]. OTOH if you use
qjackctl main window control buttons, to toggle child window
visibility and to quit application, all seems to work just fine ;) or
so I believe and been told.
5 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Lee Revell wrote:
On Thu, 2005-12-29 at 14:46 -0500, Rick Wright wrote:
Reply try #3.....
Running an up-to-date FC4/GNOME (2.6.10) system.
Rick
Rui Nuno Capela wrote:
What desktop environment and window manager are you using and which
version?
Lee
Rick Wright wrote:
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not, but
it seems that the windows don't like the presence of other windows (i.e.
an xterm from which to start QJC!) and the most prevalent offender is
the main window. Actually, it seems that upon the first restart of QJC,
the positions are remembered, but without moving any windows, a second
quit/restart results in some windows appearing cascaded from the top
left of the desktop. Window sizes are always remembered.
Can anyone else reproduce this?
I'd like the qjackctl windows (i.e. the
control window, messages,
connections, status) to open for a subsequent executation in the same
screen locations as I had them at shutdown from the last execution.
Is this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which
is good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Window positioning persistence is already featured and is default
behavior, for quite some time. AFAICS its been ever since ;). Problem
is that behavior may vary, with some glitches depending on your
particular WM. It is well known, at least to me, that window positions
aren't remembered very well if you stick to use the WM close button on
those window titles, usually the ones labeled as [X]. OTOH if you use
qjackctl main window control buttons, to toggle child window
visibility and to quit application, all seems to work just fine ;) or
so I believe and been told.
5:17 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
On Thu, 2005-12-29 at 16:00 -0500, Rick Wright wrote:
Lee Revell wrote:
OK, I just reproduced this on my Ubuntu Breezy system, Gnome 2.12.0. If
I run qjackctl, open the Messages window, move it, open the Connect
window, move that, then close the main window by clicking the X, next
time I run it the Messages window has moved back to where it started.
Surely this is a WM bug, the app can't be responsible for remembering
the position of its windows?
Lee
On Thu, 2005-12-29 at 14:46 -0500, Rick Wright
wrote:
Reply try #3.....
Running an up-to-date FC4/GNOME (2.6.10) system.
Rick
Rui Nuno Capela wrote:
What desktop environment and window manager are you using and which
version?
Lee
Rick Wright wrote:
>I'd like the qjackctl windows (i.e. the control window, messages,
>connections, status) to open for a subsequent executation in the same
>screen locations as I had them at shutdown from the last execution.
>Is this possible? I can't seem to find an option for this.
>
>All (and only those) windows that were visible from the previous
>execution do indeed appear on the subsequent application run (which
>is good), but the window positioning appears to be forgotten.
>
>Rui, if this is not currently supported, would it be possible to add
>this feature?
>
>
>
Window positioning persistence is already featured and is default
behavior, for quite some time. AFAICS its been ever since ;). Problem
is that behavior may vary, with some glitches depending on your
particular WM. It is well known, at least to me, that window positions
aren't remembered very well if you stick to use the WM close button on
those window titles, usually the ones labeled as [X]. OTOH if you use
qjackctl main window control buttons, to toggle child window
visibility and to quit application, all seems to work just fine ;) or
so I believe and been told.
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not, but
it seems that the windows don't like the presence of other windows (i.e.
an xterm from which to start QJC!) and the most prevalent offender is
the main window. Actually, it seems that upon the first restart of QJC,
the positions are remembered, but without moving any windows, a second
quit/restart results in some windows appearing cascaded from the top
left of the desktop. Window sizes are always remembered.
Can anyone else reproduce this?
5:35 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Lee Revell wrote:
On Thu, 2005-12-29 at 16:00 -0500, Rick Wright wrote:
Rui seemed to indicate that if you close those windows by toggling the
associated button on the main window (rather than the X as you did) that
the positions should persist. For me, they all do *except* the messages
window. That doesn't seem like a WM bug to me.
Try this: open the app, open the message and status windows and move
them somewhere. Then, simply toggle the buttons and see where they
reappear.
I just tried this again with the patchbay window (my first test with
patchbay) and it shows the same non-persistence behavior as the
messages window.
As far as closing the app with the quit button and then restarting, the
results are mixed as I described above. It seems that the window
positions persist (mostly) upon the first restart, but without moving
any windows, a subsequent quit/restart seems to lose window position
information. This seems app related too, no?
Rick
Lee Revell wrote:
OK, I just reproduced this on my Ubuntu Breezy system, Gnome 2.12.0. If
I run qjackctl, open the Messages window, move it, open the Connect
window, move that, then close the main window by clicking the X, next
time I run it the Messages window has moved back to where it started.
Surely this is a WM bug, the app can't be responsible for remembering
the position of its windows?
Lee
On Thu, 2005-12-29 at 14:46 -0500, Rick Wright
wrote:
Reply try #3.....
Running an up-to-date FC4/GNOME (2.6.10) system.
Rick
Rui Nuno Capela wrote:
>Rick Wright wrote:
>
>
>
>
>
>>I'd like the qjackctl windows (i.e. the control window, messages,
>>connections, status) to open for a subsequent executation in the same
>>screen locations as I had them at shutdown from the last execution.
>>Is this possible? I can't seem to find an option for this.
>>
>>All (and only those) windows that were visible from the previous
>>execution do indeed appear on the subsequent application run (which
>>is good), but the window positioning appears to be forgotten.
>>
>>Rui, if this is not currently supported, would it be possible to add
>>this feature?
>>
>>
>>
>>
>>
>Window positioning persistence is already featured and is default
>behavior, for quite some time. AFAICS its been ever since ;). Problem
>is that behavior may vary, with some glitches depending on your
>particular WM. It is well known, at least to me, that window positions
>aren't remembered very well if you stick to use the WM close button on
>those window titles, usually the ones labeled as [X]. OTOH if you use
>qjackctl main window control buttons, to toggle child window
>visibility and to quit application, all seems to work just fine ;) or
>so I believe and been told.
>
>
>
>
>
>
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not, but
it seems that the windows don't like the presence of other windows (i.e.
an xterm from which to start QJC!) and the most prevalent offender is
the main window. Actually, it seems that upon the first restart of QJC,
the positions are remembered, but without moving any windows, a second
quit/restart results in some windows appearing cascaded from the top
left of the desktop. Window sizes are always remembered.
Can anyone else reproduce this?
What desktop environment and window manager are you using and which
version?
Lee
6:22 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
Lee Revell wrote:
Rick et al.,
Been off doing some Web work but glad to see this thread working its way
along. Here's my latest results with your latest scenario:
Open QJC, open Messages and Status, observe they open right where I set
them when I first tested and replied to your posting, move them around,
toggle those two windows with their respective buttons and they persist
right where I just moved/left them. Rinse, repeat... works as expected.
Same with Patchbay.
Then, I closed down QJC with those windows still opened and re-launched
it to find the windows in the same place they were when I closed it.
Then, I closed down QJC with those windows toggled closed and
re-launched it to find that when I toggled the windows back open they
were in the same place I left them when I toggled them off before
closing QJC.
So, Fedora Core 3 fully updated with CCRMA and all core apps, Fluxbox
0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
On Thu, 2005-12-29 at 16:00 -0500, Rick Wright
wrote:
Rui seemed to indicate that if you close those windows by toggling the
associated button on the main window (rather than the X as you did)
that the positions should persist. For me, they all do *except* the
messages window. That doesn't seem like a WM bug to me.
Try this: open the app, open the message and status windows and move
them somewhere. Then, simply toggle the buttons and see where they
reappear.
I just tried this again with the patchbay window (my first test with
patchbay) and it shows the same non-persistence behavior as the
messages window.
As far as closing the app with the quit button and then restarting,
the results are mixed as I described above. It seems that the window
positions persist (mostly) upon the first restart, but without moving
any windows, a subsequent quit/restart seems to lose window position
information. This seems app related too, no?
Rick
Lee Revell wrote:
OK, I just reproduced this on my Ubuntu Breezy system, Gnome 2.12.0. If
I run qjackctl, open the Messages window, move it, open the Connect
window, move that, then close the main window by clicking the X, next
time I run it the Messages window has moved back to where it started.
Surely this is a WM bug, the app can't be responsible for remembering
the position of its windows?
Lee
On Thu, 2005-12-29 at 14:46 -0500, Rick Wright
wrote:
> Rui Nuno Capela wrote:
>
>
>
>> Rick Wright wrote:
>>
>>
>>
>>> I'd like the qjackctl windows (i.e. the control window,
>>> messages, connections, status) to open for a subsequent
>>> executation in the same screen locations as I had them at
>>> shutdown from the last execution. Is this possible? I can't
>>> seem to find an option for this.
>>>
>>> All (and only those) windows that were visible from the previous
>>> execution do indeed appear on the subsequent application run
>>> (which is good), but the window positioning appears to be
>>> forgotten.
>>>
>>> Rui, if this is not currently supported, would it be possible to
>>> add this feature?
>>>
>>>
>>>
>> Window positioning persistence is already featured and is default
>> behavior, for quite some time. AFAICS its been ever since ;).
>> Problem is that behavior may vary, with some glitches depending
>> on your particular WM. It is well known, at least to me, that
>> window positions aren't remembered very well if you stick to use
>> the WM close button on those window titles, usually the ones
>> labeled as [X]. OTOH if you use qjackctl main window control
>> buttons, to toggle child window visibility and to quit
>> application, all seems to work just fine ;) or so I believe and
>> been told.
>>
>>
>>
>>
> I am finding inconsistency in the window positioning persistence.
> Sometimes the windows appear in the same position, sometimes they
> don't. This has been tested using only the QJC main window
> control buttons as recommended above.
>
> Leaving the windows open (only testing using 4 of them: main,
> status, messages, connections) upon shutdown (quit on main window)
> and restarting QJC sometimes gives the same locations and
> sometimes not, but it seems that the windows don't like the
> presence of other windows (i.e. an xterm from which to start QJC!)
> and the most prevalent offender is the main window. Actually, it
> seems that upon the first restart of QJC, the positions are
> remembered, but without moving any windows, a second quit/restart
> results in some windows appearing cascaded from the top left of
> the desktop. Window sizes are always remembered.
>
> Can anyone else reproduce this?
>
>
What desktop environment and window manager are you using and which
version?
Lee
Reply try #3.....
Running an up-to-date FC4/GNOME (2.6.10) system.
Rick
6:32 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
pirrone wrote:
Rick Wright wrote:
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing..... I'm
using the latest version of QJC: 0.2.19a.
Rick
Lee Revell wrote:
Rick et al.,
Been off doing some Web work but glad to see this thread working its
way along. Here's my latest results with your latest scenario:
Open QJC, open Messages and Status, observe they open right where I
set them when I first tested and replied to your posting, move them
around, toggle those two windows with their respective buttons and
they persist right where I just moved/left them. Rinse, repeat...
works as expected.
Same with Patchbay.
Then, I closed down QJC with those windows still opened and
re-launched it to find the windows in the same place they were when I
closed it.
Then, I closed down QJC with those windows toggled closed and
re-launched it to find that when I toggled the windows back open they
were in the same place I left them when I toggled them off before
closing QJC.
So, Fedora Core 3 fully updated with CCRMA and all core apps, Fluxbox
0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
On Thu, 2005-12-29 at 16:00 -0500, Rick Wright
wrote:
Rui seemed to indicate that if you close those windows by toggling
the associated button on the main window (rather than the X as you
did) that the positions should persist. For me, they all do *except*
the messages window. That doesn't seem like a WM bug to me.
Try this: open the app, open the message and status windows and move
them somewhere. Then, simply toggle the buttons and see where they
reappear.
I just tried this again with the patchbay window (my first test with
patchbay) and it shows the same non-persistence behavior as the
messages window.
As far as closing the app with the quit button and then restarting,
the results are mixed as I described above. It seems that the window
positions persist (mostly) upon the first restart, but without moving
any windows, a subsequent quit/restart seems to lose window position
information. This seems app related too, no?
Rick
Lee Revell wrote:
> On Thu, 2005-12-29 at 14:46 -0500, Rick Wright wrote:
>
>
>
>
>> Rui Nuno Capela wrote:
>>
>>
>>
>>
>>> Rick Wright wrote:
>>>
>>>
>>>
>>>> I'd like the qjackctl windows (i.e. the control window,
>>>> messages, connections, status) to open for a subsequent
>>>> executation in the same screen locations as I had them at
>>>> shutdown from the last execution. Is this possible? I can't
>>>> seem to find an option for this.
>>>>
>>>> All (and only those) windows that were visible from the
>>>> previous execution do indeed appear on the subsequent
>>>> application run (which is good), but the window positioning
>>>> appears to be forgotten.
>>>>
>>>> Rui, if this is not currently supported, would it be possible
>>>> to add this feature?
>>>>
>>>>
>>>
>>> Window positioning persistence is already featured and is
>>> default behavior, for quite some time. AFAICS its been ever
>>> since ;). Problem is that behavior may vary, with some glitches
>>> depending on your particular WM. It is well known, at least to
>>> me, that window positions aren't remembered very well if you
>>> stick to use the WM close button on those window titles, usually
>>> the ones labeled as [X]. OTOH if you use qjackctl main window
>>> control buttons, to toggle child window visibility and to quit
>>> application, all seems to work just fine ;) or so I believe and
>>> been told.
>>>
>>>
>>>
>>
>> I am finding inconsistency in the window positioning
>> persistence. Sometimes the windows appear in the same position,
>> sometimes they don't. This has been tested using only the QJC
>> main window control buttons as recommended above.
>>
>> Leaving the windows open (only testing using 4 of them: main,
>> status, messages, connections) upon shutdown (quit on main
>> window) and restarting QJC sometimes gives the same locations and
>> sometimes not, but it seems that the windows don't like the
>> presence of other windows (i.e. an xterm from which to start
>> QJC!) and the most prevalent offender is the main window.
>> Actually, it seems that upon the first restart of QJC, the
>> positions are remembered, but without moving any windows, a
>> second quit/restart results in some windows appearing cascaded
>> from the top left of the desktop. Window sizes are always
>> remembered.
>>
>> Can anyone else reproduce this?
>>
>>
>
> What desktop environment and window manager are you using and which
> version?
>
> Lee
>
>
>
>
>
Reply try #3.....
Running an up-to-date FC4/GNOME (2.6.10) system.
Rick
OK, I just reproduced this on my Ubuntu Breezy system, Gnome
2.12.0. If
I run qjackctl, open the Messages window, move it, open the Connect
window, move that, then close the main window by clicking the X, next
time I run it the Messages window has moved back to where it started.
Surely this is a WM bug, the app can't be responsible for remembering
the position of its windows?
Lee
6:42 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
pirrone wrote:
I understand that Rick. If I get a chance later I'll try the version
you are using. What we now know is there is either a difference in
behavior from x.15 to x.19a or there is an interaction between the way
the program manages windows and your wm/desktop resulting in those
inconsistencies.
Frank
<snip>
So, Fedora Core 3 fully updated with CCRMA and all core apps, Fluxbox
0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing.....
I'm using the latest version of QJC: 0.2.19a.
Rick
6:58 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
pirrone wrote:
Rick Wright wrote:
OK Rick, did the upgrade and the behavior is the same. Open app, open
windows with buttons, toggle windows with buttons, close app with
windows open, close app with windows toggled off - all result in the
windows being right where they were left.
Frank
pirrone wrote:
I understand that Rick. If I get a chance later I'll try the version
you are using. What we now know is there is either a difference in
behavior from x.15 to x.19a or there is an interaction between the way
the program manages windows and your wm/desktop resulting in those
inconsistencies.
Frank
<snip>
So, Fedora Core 3 fully updated with CCRMA and all core apps,
Fluxbox 0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing.....
I'm using the latest version of QJC: 0.2.19a.
Rick
7:21 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
pirrone wrote:
pirrone wrote:
This is one example I can remember that one window will NOT remember its
position:
1. move the window from position P0 to P1.
2. close that window with the dreaded [X] WM button.
3. quit application.
Thats it, when you later relaunch QJC, the subject window will surely
reappear on the older P0 position, instead of that last P1 which is
bluntly forgotten.
This is old and "stable" behavior ;) and any suggestion on working
around it is therefore welcome. Patches' even better :))
Bye now.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Rick Wright wrote:
OK Rick, did the upgrade and the behavior is the same. Open app, open
windows with buttons, toggle windows with buttons, close app with
windows open, close app with windows toggled off - all result in the
windows being right where they were left.
pirrone wrote:
I understand that Rick. If I get a chance later I'll try the version
you are using. What we now know is there is either a difference in
behavior from x.15 to x.19a or there is an interaction between the way
the program manages windows and your wm/desktop resulting in those
inconsistencies.
Frank
<snip>
So, Fedora Core 3 fully updated with CCRMA and all core apps,
Fluxbox 0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing.....
I'm using the latest version of QJC: 0.2.19a.
Rick
30 Dec
30 Dec
11:20 a.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rui Nuno Capela wrote:
pirrone wrote:
Rui, I can confirm that this is the behavior here too when using the WM
X button. However, in all of my previous testing, I only closed the
child windows by using the buttons on the main window. One of the most
suspicious cases is when I move a window, toggle it off, then
immediately toggle it back on and it doesn't come back where I left it.
Here, the WM does seem involved, though as the window seems to come back
in a location that is either one of the cascaded locations (though no
window is present for it to cascade from) or it comes back adjacent to
and top aligned with another child window. Maybe this is a clue?
Also, trying to find some other consistent behavior to report, I can
only confirm one repeatable case: A quit/restart (having left child
windows open) and finding the windows where I left them (which does
sometimes happen, but <50% of the time), that immediately repeating this
quit/restart (doing nothing else) always results in some windows (no
noticed consistency as to which windows) appearing cascaded from the top
left and others where I left them.
The window sizes and open/close status does work persistently here.
Also, when a window does change positions on a subsequent reopen, it
seems that the new position is always at the top left, or in the case
where multiple windows relocate (which always seems to include the main
window), they come up in the cascaded layout, where each top layered
window is shifted down and right about the distance of the top-right
icon dimensions in the title bar of the underneath window.
I wish I could find more consistency to report. I am happy to go
through any procedures you may wish tested and report results.
Frank, what desktop/version are you using for testing this behavior?
Rick
pirrone wrote:
This is one example I can remember that one window will NOT remember
its position:
1. move the window from position P0 to P1.
2. close that window with the dreaded [X] WM button.
3. quit application.
Thats it, when you later relaunch QJC, the subject window will surely
reappear on the older P0 position, instead of that last P1 which is
bluntly forgotten. Rick Wright wrote:
OK Rick, did the upgrade and the behavior is the same. Open app,
open windows with buttons, toggle windows with buttons, close app
with windows open, close app with windows toggled off - all result in
the windows being right where they were left.
pirrone wrote:
> <snip>
> So, Fedora Core 3 fully updated with CCRMA and all core apps,
> Fluxbox 0.9.13, QJackCtl 0.2.15 results in the expected behavior.
>
> Frank
>
>
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing.....
I'm using the latest version of QJC: 0.2.19a.
Rick
I understand that Rick. If I get a chance later I'll try the
version you are using. What we now know is there is either a
difference in behavior from x.15 to x.19a or there is an interaction
between the way the program manages windows and your wm/desktop
resulting in those inconsistencies.
Frank
5:05 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
On Fri, 2005-12-30 at 10:19 -0500, Rick Wright wrote:
Rui Nuno Capela wrote:
Rick,
It might be interesting to see whether your locations are saved
using KDE instead of GNOME. They are persistent for me on FC4 using
KDE.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
pirrone wrote:
Rui, I can confirm that this is the behavior here too when using the WM
X button. However, in all of my previous testing, I only closed the
child windows by using the buttons on the main window. One of the most
suspicious cases is when I move a window, toggle it off, then
immediately toggle it back on and it doesn't come back where I left it.
Here, the WM does seem involved, though as the window seems to come back
in a location that is either one of the cascaded locations (though no
window is present for it to cascade from) or it comes back adjacent to
and top aligned with another child window. Maybe this is a clue?
Also, trying to find some other consistent behavior to report, I can
only confirm one repeatable case: A quit/restart (having left child
windows open) and finding the windows where I left them (which does
sometimes happen, but <50% of the time), that immediately repeating this
quit/restart (doing nothing else) always results in some windows (no
noticed consistency as to which windows) appearing cascaded from the top
left and others where I left them.
The window sizes and open/close status does work persistently here.
Also, when a window does change positions on a subsequent reopen, it
seems that the new position is always at the top left, or in the case
where multiple windows relocate (which always seems to include the main
window), they come up in the cascaded layout, where each top layered
window is shifted down and right about the distance of the top-right
icon dimensions in the title bar of the underneath window.
I wish I could find more consistency to report. I am happy to go
through any procedures you may wish tested and report results.
Frank, what desktop/version are you using for testing this behavior?
pirrone wrote:
This is one example I can remember that one window will NOT remember
its position:
1. move the window from position P0 to P1.
2. close that window with the dreaded [X] WM button.
3. quit application.
Thats it, when you later relaunch QJC, the subject window will surely
reappear on the older P0 position, instead of that last P1 which is
bluntly forgotten. Rick Wright wrote:
>
> pirrone wrote:
>
>> <snip>
>> So, Fedora Core 3 fully updated with CCRMA and all core apps,
>> Fluxbox 0.9.13, QJackCtl 0.2.15 results in the expected behavior.
>>
>> Frank
>>
>>
> Thanks, Frank.
>
> That would be the expected behavior, just not what I'm seeing.....
> I'm using the latest version of QJC: 0.2.19a.
>
> Rick
I understand that Rick. If I get a chance later I'll try the
version you are using. What we now know is there is either a
difference in behavior from x.15 to x.19a or there is an interaction
between the way the program manages windows and your wm/desktop
resulting in those inconsistencies.
Frank
OK Rick, did the upgrade and the behavior is the same. Open app,
open windows with buttons, toggle windows with buttons, close app
with windows open, close app with windows toggled off - all result in
the windows being right where they were left.
5:14 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
<snip>
Frank, what desktop/version are you using for testing this behavior?
Rick
I posted all system info for your reference several messages ago -
Fedora Core 3, CCRMA, all updates, Fluxbox 0.9.13 - IMHO a very
compelling environment in which to do comfortable and productive work -
I really don't like "desktops" with icons, "start" menus, etc.
This wm is beautiful, unobtrusive, lighting fast, highly configurable,
etc. and it never jacks around (no particular pun) with my
applications. The simple ~/.fluxbox/menu and keys and groups config
files provide extremely easy and quick access to right-click root menus,
keyboard shortcuts, and groups of files opening in single multi-tabbed
windows.
This current message, along with my earlier comments and Rui's responses
(in regards the wm interacting with the applications windowing behavior)
certainly suggest you try other "desktops" or whatever else you have on
your system - KDE, Gnome, FVWM, XFce, Windowmaker, whatever. Fedora
Core has them all and they're probably on your computer.
Frank
10:41 a.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
pirrone wrote:
pirrone wrote:
Ok. So it seems this is related to my WM? Again, using up-to-date FC4
& GNOME 2.6.10 as officially released. I do build QJC from source, though.
Rick
Rick Wright wrote:
OK Rick, did the upgrade and the behavior is the same. Open app, open
windows with buttons, toggle windows with buttons, close app with
windows open, close app with windows toggled off - all result in the
windows being right where they were left.
Frank
pirrone wrote:
I understand that Rick. If I get a chance later I'll try the version
you are using. What we now know is there is either a difference in
behavior from x.15 to x.19a or there is an interaction between the
way the program manages windows and your wm/desktop resulting in
those inconsistencies.
Frank
<snip>
So, Fedora Core 3 fully updated with CCRMA and all core apps,
Fluxbox 0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing.....
I'm using the latest version of QJC: 0.2.19a.
Rick
10:38 a.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
pirrone wrote:
Rick Wright wrote:
Frank, my apologies if my last post read with any negative tone. I
simply meant to agree on expected behavior and provide version info.
Indeed, the appreciation for help sorting out this behavior (albeit
symantic) is sincere :) .
Agreed on what we now know.
Rick
pirrone wrote:
I understand that Rick. If I get a chance later I'll try the version
you are using. What we now know is there is either a difference in
behavior from x.15 to x.19a or there is an interaction between the way
the program manages windows and your wm/desktop resulting in those
inconsistencies.
Frank
<snip>
So, Fedora Core 3 fully updated with CCRMA and all core apps,
Fluxbox 0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing.....
I'm using the latest version of QJC: 0.2.19a.
Rick
5:22 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
<snip>
Rick,
Absolutely no offense taken, and certainly none intended. My use of the
phrases "I understand that" and "what we now know" was more pastoral
or
professorial, and not helped by my disdain for emoticons. :-)
Actually, this area of program behavior is of interest and importance to
me, and my fondness for QJC and ease of testing what you report, along
with my being on vacation from school this week, all led me to stick
with this thread to a far greater extent than is my custom.
I just felt I could help you fully characterize this problem both to a
possible solution to your need and as a benefit to Rui in his development.
Frank
I understand that Rick. If I get a chance later I'll try the version
you are using. What we now know is there is either a difference in
behavior from x.15 to x.19a or there is an interaction between the
way the program manages windows and your wm/desktop resulting in
those inconsistencies.
Frank
Frank, my apologies if my last post read with any negative tone. I
simply meant to agree on expected behavior and provide version info.
Indeed, the appreciation for help sorting out this behavior (albeit
symantic) is sincere :) .
Agreed on what we now know.
Rick
29 Dec
29 Dec
7:08 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
pirrone wrote:
Just as a side note: QjackCtl's window positioning code path hasn't
changed since its dawn... but, as said before, WM differences might be
getting in between. KDE's seems pretty predictable to me ;) YMMV. OK,
just as an example hint: when you close a window with the provided WM's
X button, the GUI user program code usually gets notified only _after_
the proper window close, so asking for window extents as for later
remembrance is straight WrongProcedure(tm).
Anyhow, I'll appreciate any thoughts and others practical knowledge
about this whole issue. It might just happen that I'm doing it plain
wrong, rightly wrong from the start :)
Any help on this would be highly appreciated, as always.
Cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Rick Wright wrote:
Thanks, Frank.
That would be the expected behavior, just not what I'm seeing..... I'm
using the latest version of QJC: 0.2.19a.
Rick Lee Revell wrote:
Rick et al.,
Been off doing some Web work but glad to see this thread working its
way along. Here's my latest results with your latest scenario:
Open QJC, open Messages and Status, observe they open right where I
set them when I first tested and replied to your posting, move them
around, toggle those two windows with their respective buttons and
they persist right where I just moved/left them. Rinse, repeat...
works as expected.
Same with Patchbay.
Then, I closed down QJC with those windows still opened and
re-launched it to find the windows in the same place they were when I
closed it.
Then, I closed down QJC with those windows toggled closed and
re-launched it to find that when I toggled the windows back open they
were in the same place I left them when I toggled them off before
closing QJC.
So, Fedora Core 3 fully updated with CCRMA and all core apps, Fluxbox
0.9.13, QJackCtl 0.2.15 results in the expected behavior.
Frank
On Thu, 2005-12-29 at 16:00 -0500, Rick Wright
wrote:
> Lee Revell wrote:
>
>
>
>> On Thu, 2005-12-29 at 14:46 -0500, Rick Wright wrote:
>>
>>
>>
>>> Rui Nuno Capela wrote:
>>>
>>>
>>>
>>>> Rick Wright wrote:
>>>>
>>>>
>>>>> I'd like the qjackctl windows (i.e. the control window,
>>>>> messages, connections, status) to open for a subsequent
>>>>> executation in the same screen locations as I had them at
>>>>> shutdown from the last execution. Is this possible? I can't
>>>>> seem to find an option for this.
>>>>>
>>>>> All (and only those) windows that were visible from the
>>>>> previous execution do indeed appear on the subsequent
>>>>> application run (which is good), but the window positioning
>>>>> appears to be forgotten.
>>>>>
>>>>> Rui, if this is not currently supported, would it be possible
>>>>> to add this feature?
>>>>>
>>>>>
>>>>
>>>> Window positioning persistence is already featured and is
>>>> default behavior, for quite some time. AFAICS its been ever
>>>> since ;). Problem is that behavior may vary, with some glitches
>>>> depending on your particular WM. It is well known, at least to
>>>> me, that window positions aren't remembered very well if you
>>>> stick to use the WM close button on those window titles, usually
>>>> the ones labeled as [X]. OTOH if you use qjackctl main window
>>>> control buttons, to toggle child window visibility and to quit
>>>> application, all seems to work just fine ;) or so I believe and
>>>> been told.
>>>>
>>>>
>>>>
>>>
>>> I am finding inconsistency in the window positioning
>>> persistence. Sometimes the windows appear in the same position,
>>> sometimes they don't. This has been tested using only the QJC
>>> main window control buttons as recommended above.
>>>
>>> Leaving the windows open (only testing using 4 of them: main,
>>> status, messages, connections) upon shutdown (quit on main
>>> window) and restarting QJC sometimes gives the same locations and
>>> sometimes not, but it seems that the windows don't like the
>>> presence of other windows (i.e. an xterm from which to start
>>> QJC!) and the most prevalent offender is the main window.
>>> Actually, it seems that upon the first restart of QJC, the
>>> positions are remembered, but without moving any windows, a
>>> second quit/restart results in some windows appearing cascaded
>>> from the top left of the desktop. Window sizes are always
>>> remembered.
>>>
>>> Can anyone else reproduce this?
>>>
>>>
>>
>> What desktop environment and window manager are you using and which
>> version?
>>
>> Lee
>>
>>
>>
>>
>>
>
> Reply try #3.....
>
> Running an up-to-date FC4/GNOME (2.6.10) system.
>
> Rick
>
>
OK, I just reproduced this on my Ubuntu Breezy system, Gnome
2.12.0. If
I run qjackctl, open the Messages window, move it, open the Connect
window, move that, then close the main window by clicking the X, next
time I run it the Messages window has moved back to where it started.
Surely this is a WM bug, the app can't be responsible for remembering
the position of its windows?
Lee
Rui seemed to indicate that if you close those windows by toggling
the associated button on the main window (rather than the X as you
did) that the positions should persist. For me, they all do *except*
the messages window. That doesn't seem like a WM bug to me.
Try this: open the app, open the message and status windows and move
them somewhere. Then, simply toggle the buttons and see where they
reappear.
I just tried this again with the patchbay window (my first test with
patchbay) and it shows the same non-persistence behavior as the
messages window.
As far as closing the app with the quit button and then restarting,
the results are mixed as I described above. It seems that the window
positions persist (mostly) upon the first restart, but without moving
any windows, a subsequent quit/restart seems to lose window position
information. This seems app related too, no?
Rick
7:55 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
On Thu, 29 Dec 2005 23:12:54 +0000
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
just as an example hint: when you close a window with
the provided WM's
X button, the GUI user program code usually gets notified only _after_
the proper window close, so asking for window extents as for later
remembrance is straight WrongProcedure(tm).
Hi,
in all the toolkits i used i think i remember that one is able to catch
pretty much every window event. Especially closing of windows. So, it
should be simple to catch it before doing the real closing and storing
the geometry values somewhere. I don't know any Qt specific stuff, but
it should be doable there, too.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
30 Dec
30 Dec
4:59 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
On Fri, 2005-12-30 at 00:55 +0100, Florian Schmidt wrote:
On Thu, 29 Dec 2005 23:12:54 +0000
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
You need to overload closeEvent (QCloseEvent *event) and call your
closing routine (or put your stuff) in there.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
just as an example hint: when you close a window
with the provided WM's
X button, the GUI user program code usually gets notified only _after_
the proper window close, so asking for window extents as for later
remembrance is straight WrongProcedure(tm).
Hi,
in all the toolkits i used i think i remember that one is able to catch
pretty much every window event. Especially closing of windows. So, it
should be simple to catch it before doing the real closing and storing
the geometry values somewhere. I don't know any Qt specific stuff, but
it should be doable there, too.
12:31 a.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Lee Revell <rlrevell(a)joe-job.com> writes:
the app can't be responsible for remembering the
position of its
windows?
I would strongly disagree;). I think this is exactly the apps
responsibility. The WM should not maintain a database over every
window that an app may open. That's absurd;). Imagine apps like
Nautilus, Gimp and such. It's not very cumbersome to switch WM either
as all will be lost.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
4:46 a.m.
New subject: [linux-audio-user] Re: QJackCtl window position consistency?
Esben Stien <b0ef(a)esben-stien.name>me>, on Fri Dec 30, 2005 [07:24:47 AM] said:
Lee Revell <rlrevell(a)joe-job.com> writes:
Hi;
The application can specify its desired geometry, both size
and placement, but the window manager can ignore it. Unfortunately, it
seems like qt apps seem to mostly ignore the -geometry command line
option. So, you can blame either the app, or the wm. But in the case
of a qt app, they dont seem to make any effort to deal with the situation.
My qt app obeys the geometry, qjackctl and qdvdauthor, as a trivial test
do not...
Paul
set(a)pobox.com
the app can't be responsible for remembering
the position of its
windows?
I would strongly disagree;). I think this is exactly the apps
responsibility. The WM should not maintain a database over every
window that an app may open. That's absurd;). Imagine apps like
Nautilus, Gimp and such. It's not very cumbersome to switch WM either
as all will be lost.
5 p.m.
New subject: [linux-audio-user] Re: QJackCtl window position consistency?
On Fri, 2005-12-30 at 03:46 -0500, Paul wrote:
Esben Stien <b0ef(a)esben-stien.name>me>, on Fri Dec
30, 2005 [07:24:47 AM] said:
My apps do the same but subwindows did not honor placement in KDE
prior to 3.4.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
Lee Revell <rlrevell(a)joe-job.com> writes:
Hi;
The application can specify its desired geometry, both size
and placement, but the window manager can ignore it. Unfortunately, it
seems like qt apps seem to mostly ignore the -geometry command line
option. So, you can blame either the app, or the wm. But in the case
of a qt app, they dont seem to make any effort to deal with the situation.
My qt app obeys the geometry, qjackctl and qdvdauthor, as a trivial test
do not...
the app can't be responsible for remembering
the position of its
windows?
I would strongly disagree;). I think this is exactly the apps
responsibility. The WM should not maintain a database over every
window that an app may open. That's absurd;). Imagine apps like
Nautilus, Gimp and such. It's not very cumbersome to switch WM either
as all will be lost.
4:54 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
On Thu, 2005-12-29 at 16:23 -0500, Lee Revell wrote:
On Thu, 2005-12-29 at 16:00 -0500, Rick Wright wrote:
Yes. The app is responsible for remembering the location of its
windows. This is done in Qt using Widget::setGeometry,
Widget::frameGeometry, and Widget::geometry. You have to remember to
capture all of the window positions on close (of any kind). I use
QSettings to save and restore window locations (and toolbar locations).
One problem in KDE prior to 3.2 (I think that was the version),
sub-windows do not always come back in the correct location. When I
went to FC4 (uses KDE 3.4) this was corrected.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
Lee Revell wrote:
OK, I just reproduced this on my Ubuntu Breezy system, Gnome 2.12.0. If
I run qjackctl, open the Messages window, move it, open the Connect
window, move that, then close the main window by clicking the X, next
time I run it the Messages window has moved back to where it started.
Surely this is a WM bug, the app can't be responsible for remembering
the position of its windows?
On Thu, 2005-12-29 at 14:46 -0500, Rick Wright
wrote:
Reply try #3.....
Running an up-to-date FC4/GNOME (2.6.10) system.
Rick
Rui Nuno Capela wrote:
>Rick Wright wrote:
>
>
>
>>I'd like the qjackctl windows (i.e. the control window, messages,
>>connections, status) to open for a subsequent executation in the same
>>screen locations as I had them at shutdown from the last execution.
>>Is this possible? I can't seem to find an option for this.
>>
>>All (and only those) windows that were visible from the previous
>>execution do indeed appear on the subsequent application run (which
>>is good), but the window positioning appears to be forgotten.
>>
>>Rui, if this is not currently supported, would it be possible to add
>>this feature?
>>
>>
>>
>Window positioning persistence is already featured and is default
>behavior, for quite some time. AFAICS its been ever since ;). Problem
>is that behavior may vary, with some glitches depending on your
>particular WM. It is well known, at least to me, that window positions
>aren't remembered very well if you stick to use the WM close button on
>those window titles, usually the ones labeled as [X]. OTOH if you use
>qjackctl main window control buttons, to toggle child window
>visibility and to quit application, all seems to work just fine ;) or
>so I believe and been told.
>
>
>
>
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not, but
it seems that the windows don't like the presence of other windows (i.e.
an xterm from which to start QJC!) and the most prevalent offender is
the main window. Actually, it seems that upon the first restart of QJC,
the positions are remembered, but without moving any windows, a second
quit/restart results in some windows appearing cascaded from the top
left of the desktop. Window sizes are always remembered.
Can anyone else reproduce this?
What desktop environment and window manager are you using and which
version?
Lee
29 Dec
29 Dec
3:58 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
Rui Nuno Capela wrote:
I should add that toggling the windows on/off using the buttons on the
main window gives mixed position persistence results. I found that only
the "messages" window (of those I am using) consistently comes back in
the top-left cascaded position. The others' position do persist.
Rick
Rick Wright wrote:
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not,
but it seems that the windows don't like the presence of other windows
(i.e. an xterm from which to start QJC!) and the most prevalent
offender is the main window. Actually, it seems that upon the first
restart of QJC, the positions are remembered, but without moving any
windows, a second quit/restart results in some windows appearing
cascaded from the top left of the desktop. Window sizes are always
remembered.
Can anyone else reproduce this?
Rick
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the
same screen locations as I had them at shutdown from the last
execution. Is this possible? I can't seem to find an option for this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which
is good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to add
this feature?
Window positioning persistence is already featured and is default
behavior, for quite some time. AFAICS its been ever since ;). Problem
is that behavior may vary, with some glitches depending on your
particular WM. It is well known, at least to me, that window
positions aren't remembered very well if you stick to use the WM
close button on those window titles, usually the ones labeled as [X].
OTOH if you use qjackctl main window control buttons, to toggle child
window visibility and to quit application, all seems to work just
fine ;) or so I believe and been told.
4:15 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
Rick Wright wrote:
Negative on that too Rick. Toggling them has no effect on position.
Rui Nuno Capela wrote:
I should add that toggling the windows on/off using the buttons on the
main window gives mixed position persistence results. I found that
only the "messages" window (of those I am using) consistently comes
back in the top-left cascaded position. The others' position do persist.
Rick
Rick Wright wrote:
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not,
but it seems that the windows don't like the presence of other
windows (i.e. an xterm from which to start QJC!) and the most
prevalent offender is the main window. Actually, it seems that upon
the first restart of QJC, the positions are remembered, but without
moving any windows, a second quit/restart results in some windows
appearing cascaded from the top left of the desktop. Window sizes
are always remembered.
Can anyone else reproduce this?
Rick
I'd like the qjackctl windows (i.e. the control window, messages,
connections, status) to open for a subsequent executation in the
same screen locations as I had them at shutdown from the last
execution. Is this possible? I can't seem to find an option for
this.
All (and only those) windows that were visible from the previous
execution do indeed appear on the subsequent application run (which
is good), but the window positioning appears to be forgotten.
Rui, if this is not currently supported, would it be possible to
add this feature?
Window positioning persistence is already featured and is default
behavior, for quite some time. AFAICS its been ever since ;).
Problem is that behavior may vary, with some glitches depending on
your particular WM. It is well known, at least to me, that window
positions aren't remembered very well if you stick to use the WM
close button on those window titles, usually the ones labeled as
[X]. OTOH if you use qjackctl main window control buttons, to toggle
child window visibility and to quit application, all seems to work
just fine ;) or so I believe and been told.
4:14 p.m.
New subject: [linux-audio-user] QJackCtl window position consistency?
Rick Wright wrote:
I am finding inconsistency in the window positioning persistence.
Sometimes the windows appear in the same position, sometimes they
don't. This has been tested using only the QJC main window control
buttons as recommended above.
Leaving the windows open (only testing using 4 of them: main, status,
messages, connections) upon shutdown (quit on main window) and
restarting QJC sometimes gives the same locations and sometimes not,
but it seems that the windows don't like the presence of other windows
(i.e. an xterm from which to start QJC!) and the most prevalent
offender is the main window. Actually, it seems that upon the first
restart of QJC, the positions are remembered, but without moving any
windows, a second quit/restart results in some windows appearing
cascaded from the top left of the desktop. Window sizes are always
remembered.
Can anyone else reproduce this?
Rick
Rick,
Everything works as expected in Fluxbox even without asking the WM to
remember window positions. All four windows arrange themselves around
the middle of the screen with the QJC main opening by default in the
upper left corner. With an xterm open as a test, the main window tiles
itself to the right of the terminal window as is the default behavior,
but all four of the program's windows open where they were before and
without the terminal.
Frank
6701
days inactive
6707
days old
linux-audio-user@lists.linuxaudio.org
41 comments
15 participants
participants (15)
-
Dave Phillips -
Esben Stien -
Florian Schmidt -
Garett Shulman -
Jan Depner -
Lars Luthman -
Lee Revell -
Mark Knecht -
michel pondeville -
Nigel Henry -
Paul -
pirrone -
Rick Wright -
Rui Nuno Capela -
Sean Bolton