Call for WhySynth presets

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Call for WhySynth presets

Sean Bolton-2
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
 

Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Garett Shulman
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
>  


Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Sean Bolton-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Dave Phillips
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


Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Lars Luthman
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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Dave Phillips
Lars Luthman wrote:

>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.
>
>  
>
Thanks Lars, it's just what I needed. :)

Best,

dp



Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

nigel henry
In reply to this post by Lars Luthman
On Wednesday 28 December 2005 13:26, Lars Luthman wrote:

> 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.

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.
Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Dave Phillips
In reply to this post by Dave Phillips
Lars Luthman 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.
>
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

Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Sean Bolton-2
In reply to this post by Dave Phillips
Hi Dave,

On Dec 28, 2005, at 4:26 AM, Dave Phillips wrote:

>  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.
>>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Lars Luthman
In reply to this post by Dave Phillips
On Wed, 2005-12-28 at 11:33 -0500, Dave Phillips wrote:

> Lars Luthman 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.
> >
> 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

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

Dave Phillips
In reply to this post by Sean Bolton-2
Sean Bolton wrote:

> Hi Dave,
>
> On Dec 28, 2005, at 4:26 AM, Dave Phillips wrote:
>
>>  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)?

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...

> 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:
>
>>>> '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 ?
>
>
> 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.

> HTH.  Looking forward to the demo!

Thanks a lot, Sean. On to the music... :)

Best,

dp

Reply | Threaded
Open this post in threaded view
|

Re: Call for WhySynth presets

michel pondeville
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&meta=
Michel
----- Original Message -----
From: "Dave Phillips" <[hidden email]>
To: "Sean Bolton" <[hidden email]>
Cc: "A list for linux audio users" <[hidden email]>
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:
>>
>>>  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)?
>
> 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...
>
>> 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:
>>
>>>>> '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 ?
>>
>>
>> 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.
>
>> HTH.  Looking forward to the demo!
>
> Thanks a lot, Sean. On to the music... :)
>
> Best,
>
> dp
>

Reply | Threaded
Open this post in threaded view
|

QJackCtl window position consistency?

riwright
In reply to this post by Sean Bolton-2

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
Reply | Threaded
Open this post in threaded view
|

Re: QJackCtl window position consistency?

Mark Knecht
On 12/29/05, Rick Wright <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: QJackCtl window position consistency?

Frank-112
In reply to this post by riwright
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

Reply | Threaded
Open this post in threaded view
|

Re: QJackCtl window position consistency?

Rui Nuno Capela
In reply to this post by riwright
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: QJackCtl window position consistency?

riwright


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?

Rick

Reply | Threaded
Open this post in threaded view
|

Re: QJackCtl window position consistency?

riwright


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?
>
> Rick

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
Reply | Threaded
Open this post in threaded view
|

Re: QJackCtl window position consistency?

Lee Revell
In reply to this post by riwright
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 | Threaded
Open this post in threaded view
|

Re: QJackCtl window position consistency?

Frank-112
In reply to this post by riwright
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
123