Lynn Walls | 6 Nov 00:29 2009
Picon
Picon

Re: beta8 for 3.8 - Observations

1. So far, no operational problems found.

2. Full screen window handling has returned to previous version 3.7
    behavior, which is much preferred to the behavior of 3.8 Beta 7.
    Now, with Beta 8,
    a.) the full screen no longer reverts to windowed mode if the
        mouse is moved to another display (i.e. another display device
        on the computer gets focus),
    b.) the full screen paints in one single "flash" instead of the
        sequential ripple of objects coming into view over a period of
        about 2 seconds seconds,
    c.) the task bar can no longer be activated "over" the jOrgan
        full screen display.

Lynn
------------------------------------------------------------------------

Sven Meier wrote:
> Hi all,
> 
> I'd like to get 3.8 out of the door, so here's another beta:
> 
>     
> http://sourceforge.net/projects/jorgan/files/jorgan-installer/3.8/jOrgan-3.8-beta8-installer1.exe/download
> 
> I wasn't able to reproduce any performance problems. Note that the new 
> memory extension has no negative impact on the overall performance of 
> jOrgan.
> If you do experience sluggish behavior in the application, please try to 
> isolate the cause and give specific feedback.
(Continue reading)

Rick (greenfox | 6 Nov 00:37 2009
Picon

Re: beta8 for 3.8

Slow combination changes has been noted on Linux applications.  I had it 
with jOrgan V3.7 on Ubuntu 9.04.  I am not aware of a resolution to 
this.  I have now upgraded to Ubuntu 9.10 however have not had a chance 
to try jOrgan on it yet.

This I believe is a different symptom from the slow combination set time 
noted by some in jOrgan V3.8b7 in Windows applications.  I did not 
experience this problem.

Regards
Rick

jsouth wrote:
> Sven Meier wrote:
>> Hi all,
>>
>> I'd like to get 3.8 out of the door, so here's another beta:
>>
>>     
>> http://sourceforge.net/projects/jorgan/files/jorgan-installer/3.8/jOrgan-3.8-beta8-installer1.exe/download
>>
>> I wasn't able to reproduce any performance problems. Note that the new 
>> memory extension has no negative impact on the overall performance of 
>> jOrgan.
>> If you do experience sluggish behavior in the application, please try to 
>> isolate the cause and give specific feedback.
>>
>> Please give it this beta a final test drive.
>>
>> Thanks
(Continue reading)

Lynn Walls | 6 Nov 01:05 2009
Picon
Picon

Re: beta8 for 3.8 - Observations

Additional observation:

  3. The Piston capturing (captor function) has also returned to its
     former behavior.  The time to capture any piston, regardless of
     the number of referenced elements is almost intantaneous (as
     opposed to about 12 seconds for "generals" and 4-5 seconds for
     "divisionals").

CLW
---------------------------------------------------------------

Lynn Walls wrote:
> 1. So far, no operational problems found.
> 
> 2. Full screen window handling has returned to previous version 3.7
>     behavior, which is much preferred to the behavior of 3.8 Beta 7.
>     Now, with Beta 8,
>     a.) the full screen no longer reverts to windowed mode if the
>         mouse is moved to another display (i.e. another display device
>         on the computer gets focus),
>     b.) the full screen paints in one single "flash" instead of the
>         sequential ripple of objects coming into view over a period of
>         about 2 seconds seconds,
>     c.) the task bar can no longer be activated "over" the jOrgan
>         full screen display.
> 
> Lynn
> ------------------------------------------------------------------------
> 
> Sven Meier wrote:
(Continue reading)

Lynn Walls | 6 Nov 01:30 2009
Picon
Picon

New skin for Captor (Set) button wanted

Does anyone have a round "piston" button skin style that turns BRIGHT 
red or green when the Captor button has been armed, and returns to light 
grey when the Captor has deactivated?

This Theatre skin that I have been using only turns to a slightly darker 
shade of grey when the Captor has been armed.  The problem is that if I 
then inadvertently click on a non-capturable button (a button NOT 
referenced by the Captor), the Captor STAYS ARMED.

If I fail to notice this condition (due to the subtle difference in 
shades of grey between armed and deactivated states), I may "ruin" the 
saved setting of the next capturable piston that I click on.

Would anyone else find a piston skin that has dramatic color contrasts 
between the active and inactive states useful as well?

Would it be a nice feature to have a "timeout" property on lockable 
elements that, when non-zero, would automatically return the state of 
the element to Active=false after a specified number of seconds.

Sven, weren't you thinking of designing some timer-based logic for some 
other function (that I cannot recall just now)?

Lynn

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
(Continue reading)

Rick (greenfox | 6 Nov 01:48 2009
Picon

Re: New skin for Captor (Set) button wanted

I agree that would be useful.  Both the more visual indication particularly and possibly the time out function.  I have found the theatre skin piston I am using to be a very subtle difference when active, and have messed up a piston or two when distracted in the process of setting a combination.

I suspect that editing the Skin would not be particularly difficult, however with other things higher on the priority list I have not looked into the detail of doing it.

Maybe we could make the "Set" piston turn into a flashing red star once pressed waiting for a piston to be selected!

Regards
Rick

Lynn Walls wrote:
Does anyone have a round "piston" button skin style that turns BRIGHT red or green when the Captor button has been armed, and returns to light grey when the Captor has deactivated? This Theatre skin that I have been using only turns to a slightly darker shade of grey when the Captor has been armed. The problem is that if I then inadvertently click on a non-capturable button (a button NOT referenced by the Captor), the Captor STAYS ARMED. If I fail to notice this condition (due to the subtle difference in shades of grey between armed and deactivated states), I may "ruin" the saved setting of the next capturable piston that I click on. Would anyone else find a piston skin that has dramatic color contrasts between the active and inactive states useful as well? Would it be a nice feature to have a "timeout" property on lockable elements that, when non-zero, would automatically return the state of the element to Active=false after a specified number of seconds. Sven, weren't you thinking of designing some timer-based logic for some other function (that I cannot recall just now)? Lynn ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ jOrgan-user mailing list jOrgan-user <at> lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
jOrgan-user mailing list
jOrgan-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Rick (greenfox | 6 Nov 02:04 2009
Picon

Re: Mapping / Ranging pistons from the console

Is there something I have missed, or is the only way to "Map" or "Range" 
the pistons on a jOrgan console by setting the "Referenced" Elements (As 
I have done).

Would it be possible to have a "Map" (or "Range") piston like the "Set" 
piston, that would record which tabs were selected to be addressed by 
that piston, thereby making it "Mappable" from the live console rather 
than being a "Construct" mode function?

Would it be possible for this setting to be stored in the .memory file 
that also holds the combination data for the pistons?

Does anyone else think this could be useful?

Regards
Rick

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Jacques LEVY | 6 Nov 02:17 2009
Picon

Re: New skin for Captor (Set) button wanted

Hi Lynn,

> "piston" button skin style that turns BRIGHT  red or green

1/ Save your skin zip.file - it can help  :-)
2/Open the zip file
3/Copy piston1.png and paste it in any folder  (You cannot modify it 
directly in the zip file)
4/Open the pasted Piston1.png with paint.net (free) for instance
You will have in paint.net a lot of possibilities (colour, contrast, 
brightness ....)
When you have finished, just copy and paste your changed piston1.png in the 
still opened zip file.
You will be asked to confirm the replace.
That's all !

I modified this piston1 in all my skins files because I too needed a less 
subtle difference !

Jacques

----- Original Message ----- 
From: "Lynn Walls" <lwalls <at> comcast.net>
To: <jorgan-user <at> lists.sourceforge.net>
Sent: Friday, November 06, 2009 1:30 AM
Subject: [jOrgan-user] New skin for Captor (Set) button wanted

> Does anyone have a round "piston" button skin style that turns BRIGHT
> red or green when the Captor button has been armed, and returns to light
> grey when the Captor has deactivated?
>
> This Theatre skin that I have been using only turns to a slightly darker
> shade of grey when the Captor has been armed.  The problem is that if I
> then inadvertently click on a non-capturable button (a button NOT
> referenced by the Captor), the Captor STAYS ARMED.
>
> If I fail to notice this condition (due to the subtle difference in
> shades of grey between armed and deactivated states), I may "ruin" the
> saved setting of the next capturable piston that I click on.
>
> Would anyone else find a piston skin that has dramatic color contrasts
> between the active and inactive states useful as well?
>
> Would it be a nice feature to have a "timeout" property on lockable
> elements that, when non-zero, would automatically return the state of
> the element to Active=false after a specified number of seconds.
>
> Sven, weren't you thinking of designing some timer-based logic for some
> other function (that I cannot recall just now)?
>
> Lynn
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus 
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> jOrgan-user mailing list
> jOrgan-user <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jorgan-user 

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Lynn Walls | 6 Nov 02:19 2009
Picon
Picon

Re: New skin for Captor (Set) button wanted

Rick,

You are absolutely correct on the ease of editing.  In the time since my 
previous post, I used a text editor to change the skin.xml file by 
cloning the "piston" <style>...</style> object and modifying its name to 
be "set".  Then I changed the two graphic references "piston0.png" and 
"piston1.png" in the cloned style object to "set0.png" and "set1.png", 
respectively.

Then I made a copy of the piston0.png file and renamed it set0.png.

Then I made another copy of piston0.png and edited it with GIMP using 
its Hue/Saturation tool to change the image to a bright GREEN.

Then I saved this green piston image as set1.png.

Then I copied the modified skin.xml file and the two new piston image 
files: set0.png and set1.png back into the skin .zip file.

All this took less time to do than it took to write this post.

It works perfectly.  I withdraw my request for a high contrast piston skin!

Lynn
--------------------------------------------------------------------

Rick (greenfox) wrote:

> I suspect that editing the Skin would not be particularly difficult, 
> however with other things higher on the priority list I have not looked 
> into the detail of doing it.

> 
> Lynn Walls wrote:
>> Does anyone have a round "piston" button skin style that turns BRIGHT 
>> red or green when the Captor button has been armed, and returns to light 
>> grey when the Captor has deactivated?
>>
>> This Theatre skin that I have been using only turns to a slightly darker 
>> shade of grey when the Captor has been armed.  The problem is that if I 
>> then inadvertently click on a non-capturable button (a button NOT 
>> referenced by the Captor), the Captor STAYS ARMED.
>>
>> If I fail to notice this condition (due to the subtle difference in 
>> shades of grey between armed and deactivated states), I may "ruin" the 
>> saved setting of the next capturable piston that I click on.
>>
>> Would anyone else find a piston skin that has dramatic color contrasts 
>> between the active and inactive states useful as well?
>>
>> Would it be a nice feature to have a "timeout" property on lockable 
>> elements that, when non-zero, would automatically return the state of 
>> the element to Active=false after a specified number of seconds.
>>
>> Sven, weren't you thinking of designing some timer-based logic for some 
>> other function (that I cannot recall just now)?
>>
>> Lynn
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>> trial. Simplify your report design, integration and deployment - and focus on 
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> jOrgan-user mailing list
>> jOrgan-user <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jorgan-user
>>
>>   
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> jOrgan-user mailing list
> jOrgan-user <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jorgan-user

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Lynn Walls | 6 Nov 02:26 2009
Picon
Picon

Re: Mapping / Ranging pistons from the console

Rick,

I know exactly what you are looking for.  Its the way MidiTzer does it.

The tedious task of identifying which stops and coulplers should be 
captured by each piston would no longer be a laborious "Construct Mode" 
job, but rather it would be a quick and dynamically changeable performer 
manipulation of console buttons on the organ console screen itself.

Even better, as with MidiTzer, the dynamic reference mapping of stops 
and couplers to pistons could be at the Memory level such that the 
mapping of a given piston could be DIFFERENT from one level to another.

Unfortunately, this feature could be a lot of work for Sven.

Lynn
------------------------------------------------------------------------

Rick (greenfox) wrote:
> Is there something I have missed, or is the only way to "Map" or "Range" 
> the pistons on a jOrgan console by setting the "Referenced" Elements (As 
> I have done).
> 
> Would it be possible to have a "Map" (or "Range") piston like the "Set" 
> piston, that would record which tabs were selected to be addressed by 
> that piston, thereby making it "Mappable" from the live console rather 
> than being a "Construct" mode function?
> 
> Would it be possible for this setting to be stored in the .memory file 
> that also holds the combination data for the pistons?
> 
> Does anyone else think this could be useful?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Lynn Walls | 6 Nov 02:33 2009
Picon
Picon

Re: New skin for Captor (Set) button wanted

Thanks, Jacques.

Just before I read your post, I did essentially the very same thing, 
except that I used the GIMP tool rather than paint.net to change the color.

Also, rather than change the piston button itself to have a bright green 
"active state" color, I actually created a whole new skin object called 
"set".  That way my actual Piston buttons still show the two shades of 
grey, while my Set captor button turns a bright green when armed.

Lynn
-------------------------------------------------------------------

Jacques LEVY wrote:
> Hi Lynn,
> 
>> "piston" button skin style that turns BRIGHT  red or green
> 
> 1/ Save your skin zip.file - it can help  :-)
> 2/Open the zip file
> 3/Copy piston1.png and paste it in any folder  (You cannot modify it 
> directly in the zip file)
> 4/Open the pasted Piston1.png with paint.net (free) for instance
> You will have in paint.net a lot of possibilities (colour, contrast, 
> brightness ....)
> When you have finished, just copy and paste your changed piston1.png in the 
> still opened zip file.
> You will be asked to confirm the replace.
> That's all !
> 
> I modified this piston1 in all my skins files because I too needed a less 
> subtle difference !
> 
> Jacques
> 
> 
> ----- Original Message ----- 
> From: "Lynn Walls" <lwalls <at> comcast.net>
> To: <jorgan-user <at> lists.sourceforge.net>
> Sent: Friday, November 06, 2009 1:30 AM
> Subject: [jOrgan-user] New skin for Captor (Set) button wanted
> 
> 
>> Does anyone have a round "piston" button skin style that turns BRIGHT
>> red or green when the Captor button has been armed, and returns to light
>> grey when the Captor has deactivated?
>>
>> This Theatre skin that I have been using only turns to a slightly darker
>> shade of grey when the Captor has been armed.  The problem is that if I
>> then inadvertently click on a non-capturable button (a button NOT
>> referenced by the Captor), the Captor STAYS ARMED.
>>
>> If I fail to notice this condition (due to the subtle difference in
>> shades of grey between armed and deactivated states), I may "ruin" the
>> saved setting of the next capturable piston that I click on.
>>
>> Would anyone else find a piston skin that has dramatic color contrasts
>> between the active and inactive states useful as well?
>>
>> Would it be a nice feature to have a "timeout" property on lockable
>> elements that, when non-zero, would automatically return the state of
>> the element to Active=false after a specified number of seconds.
>>
>> Sven, weren't you thinking of designing some timer-based logic for some
>> other function (that I cannot recall just now)?
>>
>> Lynn
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus 
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> jOrgan-user mailing list
>> jOrgan-user <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jorgan-user 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> jOrgan-user mailing list
> jOrgan-user <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jorgan-user
> 

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Gmane