Discussion:
[jOrgan-user] [QUESTION/PROP] FluidSynth costumizer tab
BCA
2011-04-13 15:35:10 UTC
Permalink
Hi,

I'm thinking about the buffers, buffer size and gain settings in the FS
Costumizer tab. Sven has agreed to include the gain box in the costumizer in
the next version.

I just love to alter FS gain and other options for multiple sound elements,
in a bulk operation, marking and operating all elements at once.

Is there any way to represent the various FS elements in the costumizer in a
form, bulk operations are still possible?

Regards
Bernd



--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3447481.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Sven Meier
2011-04-13 16:33:50 UTC
Permalink
Make a suggestion ;).

Sven
Post by BCA
Hi,
I'm thinking about the buffers, buffer size and gain settings in the FS
Costumizer tab. Sven has agreed to include the gain box in the costumizer in
the next version.
I just love to alter FS gain and other options for multiple sound elements,
in a bulk operation, marking and operating all elements at once.
Is there any way to represent the various FS elements in the costumizer in a
form, bulk operations are still possible?
Regards
Bernd
--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3447481.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
BCA
2011-04-13 18:31:19 UTC
Permalink
hm, perhaps something like this?
When chosen, global values inserted magically into the List view, when
chosen? Apply button?
Bernd

Loading Image...


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3447922.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
BCA
2011-04-13 18:50:53 UTC
Permalink
yet better
Loading Image...


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3447952.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Sven Meier
2011-04-16 19:29:52 UTC
Permalink
Hi Bernd,

for 3.13 I'm not decided yet, but I won't forget your suggestion.

Regards

Sven
Post by BCA
yet better
http://jorgan.999862.n4.nabble.com/file/n3447952/FS_Costumizer_view2.jpg
--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3447952.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
BCA
2011-04-17 11:44:18 UTC
Permalink
Hi Sven,

thank you - but since you keeped the gain in the construction mode FS
element (I wasn't quite sure if you'd do so), I'm not quite sure anymore if
it's necessary to alter something "cosmetically" in the Costumizer...

Perhaps just for later on - I really love those list view setups (connector
etc.), since in my multi-instance models, the Costumizer always fills the
whole screen ;-)).

Regards
Bernd.


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3455342.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
DellAnderson
2011-04-18 02:19:03 UTC
Permalink
Having struggled with multi-instance FluidSynth long enough to be tired of
them, I think the true answer will be when Sven is able to break apart the
sound triggering and generation from the dispositions.

I only have 3 different MIDI keyboards
There are (conservatively) 12 dispositions

Why should I have to configure jOrgan 12 times? If there was a separate
module for configuring to the keyboard (with the option to 'save settings'
under different names if necessary), it would truly simplify setup.

My Allen's
Swell is ALWAYS channel one
GREAT is ALWAYS channel two
CHOIR is ALWAYS channel three
PEDAL is ALWAYS channel four...

My casio keyboard only uses one or two (if split) channels (usually I set to
channel one, but I could set to polyphony I think)

My roland keyboard is the same

whether it is the Obie, the Christie, the you name it. Disposition
creators could set defaults that would work (other than jorgan keyboard) and
if we want, we could tweak them as a settings preference which could be
saved or loaded at will.

This will be one more step towards nirvana

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3456456.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
BCA
2011-04-18 02:58:41 UTC
Permalink
Hello Dell,

you seem to have an idea for a general keyboard hardware setup,
independently of the disposition file.
Please make this a new proposal to the list, since this is a new topic.

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3456494.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
DellAnderson
2011-04-20 17:22:05 UTC
Permalink
Post by BCA
Hello Dell,
you seem to have an idea for a general keyboard hardware setup,
independently of the disposition file.
Please make this a new proposal to the list, since this is a new topic.
Regards
Bernd.
Hello Bernd,

I wish I could take credit for the idea, but I don't think this is a new
idea - it has been raised on more than one occasion before by Lynn, Sven,
etc. I did not find the latest discussion, but a similar one was here:
http://jorgan.999862.n4.nabble.com/console-settings-td1676665i20.html#a1677683
http://jorgan.999862.n4.nabble.com/console-settings-td1676665i20.html#a1677683

The complaints against it were that it might be too complex, but the way I
imagine it, things would be much simpler for the user. Basically jOrgan
would be divided into two more or less independent 'modules' which were
completely compatible with each other, but individually could be modified
and saved in multiple configurations by the user.

A) The keyboard controller module which the user configures once, and only
once, for each of the keyboard controllers he may at any time in the future
use with jOrgan. Here is where one tells the jOrgan_controller that my
Allen has three manuals, and the top manual is MIDI channel #1, next down is
MIDI channel #2 etc. It would also be where you configure your swell
pedals, crescendo pedal etc --- these are likely mechanically, or
electronically limited in output by whatever midi converter your unique
situation has, so these would NOT need to be changed ever....for that
particular console. This configuration setting could be saved as "ALLEN
Console"

Of course, I also have a single keyboard controller from Roland - in that
has 88 keys, a soft expression pedal, and so on. I always use MIDI channel
#1 for this one, so I would map the jOrgan_controller abstract swell, great,
and choir and pedal manuals to channel #1 (or whatever I choose).

B) The jOrgan module is where dispositions are created and exchanged between
users. They would still be infinitely configurable by disposition creators
and end users as they are today, but there would also be a wonderful new
possibility: Instead of (or in addition to) defaulting to the jOrgan
virtual keyboard (nice for a lookiloo, but who really plays on a jOrgan
virtual keyboard?), organ dispositions would have built in abstractions of
the most probable 'standard' abstract organ configurations. For example,
organ disposition creators would create their disposition with suggested
configurations for:
00) jOrgan virtual keyboard
0) 1 manual, no pedals
1) 2 manuals and pedals & expression etc
2) 3 manuals and pedals & expression etc
3) 4 manuals and pedals & expression etc
(I'm assuming that 5 manual dispositions could be made as well, but the
number of users decreases)

Restated, the jOrgan Module (Item B above) would allow disposition creators
to suggest how they imagine their disposition to be implemented, in an
abstracted form - top manual, middle manual, bottom manual, pedals...for a
specified number of available manuals and pedalboard.

The user's Keyboard Module (Item A above) would allow users to setup,
configure, and save one or more hardware configurations that tell the
Keyboard Module which MIDI channels correspond to these abstract TOP,
MIDDLE, BOTTOM, PEDAL keyboards, or if they even exist! Done once, done
for always!

Changing to a different keyboard would be as simple as "LOAD KEYBOARD MODULE
SETTINGS" in Item A.
Changing to a different disposition would be as simple as "LOAD jOrgan
MODULE DISPOSITION" in Item B.

The beauty of this is, when Bernd, Rick, or Panos comes up with a new 2
manual disposition, all I would have to do is open it with the jOrgan
MODULE, and my physical console would work without having to reconfigure
everything until I moved my computer over to a different console, and then I
would only have to "LOAD KEYBOARD MODULE SETTINGS" once, and that console
would be the active one for then on.

Further possible refinements - a cascading Default configuration for the
jOrgan module - in other words, allow disposition creators to say "If the
user's 'abstract organ definition' has 3 manuals + pedal, set up the Swell
as the top manual, the Great as the middle, and the Choir as the lowest, and
the "Solo" as the top manual as well. If the user's current abstract organ
definition includes a fourth manual, make the "Solo" the top manual and if
there are 5 manuals, make the "Recit" the bottom manual or whatever is more
historically accurate for the organ disposition creators ideas.

In other words, we are organizing dispositions by concepts, not getting
stuck in remembering that manual #1 is the top manual on this particular
keyboard etc.

I apologize if this isn't clear, but it is a method used to separate out
components of many higher end software. In fact, it is analogous to the way
jOrgan works with JAVA so that jOrgan will run on PC, Mac, or Linux without
having to completely reprogram jOrgan...there is an abstract 'Virtual
machine' layer in between provided by the Java RE which makes programming in
Java cross platform.

What I am suggesting is making jOrgan dispositions 'cross platform' between
various hardware consoles...The end user would be responsible for
configuring the specific implementations for each of his hardware consoles
(ONCE each!) and saving those, but once done, he or she would not have to
tediously reconfigure (customize) each disposition, providing he was
satisfied with the Disposition creators vision -- if not, the disposition
should be able to be tweaked just as it is today, only in reference to the
underlying virtual organ.

I believe Graham does something very akin to this using JACK, and that may
be an interval possibility, but I don't see any show-stopper reason why this
functionality could not be built into jOrgan. Any virtual midi JACK tricks
could be used in addition to that as gravy for the super techies.

best,

Dell

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463640.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
DellAnderson
2011-04-20 17:30:04 UTC
Permalink
In case I wasn't completely clear, my proposed 'modules' could be relatively
invisible to the end user, (in other words, not necessary to have two
separate windows open), and they could be available by a file menu:
1) FILE -> LOAD (or SAVE) jOrgan CONSOLE (to change to a different hardware
console saved configuration)
or
2) FILE -> LOAD (or SAVE) jOrgan DISPOSITION (to change to a different
virtual organ disposition)

best,

Dell

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463660.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
BCA
2011-04-20 17:41:22 UTC
Permalink
Hi Dell,

I think your approach is very near to the approach of Rick.

If I've understood this alright, this proposal is excellent.

Additionally to the standard setups, special configuration masks could be
added by the disposition architect, and once set up by the user, upgraded
dispositions could always point to the same mask.

Great.

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463692.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
DellAnderson
2011-04-20 18:07:53 UTC
Permalink
Bernd and Geert and Rick and all,

If I understand correctly what Rick is proposing, I think it is very close
(if not identical) to my description.

Essentially what I am pointing out are two things:
1) that most users have a limited number of physical consoles, and it is
fairly annoying to have to reconfigure ALL the settings for each new version
of a disposition (worth it, but somewhat tedious).
2) most dispositions are ideally suited for only one or two standard
console configurations (usu. 1,2, or 3 manuals + pedals). If it is a
harpsichord, it is usually 1 or 2 manuals (unless a pedal harpsichord) etc.

These basic 'abstractions' could be standardized and more developed as
needed in a wiki-like fashion (and documented on the Wiki page under
'disposition creation' or context help files in jOrgan (if there are some).
Ideally, this would not require any change in the actual jOrgan Console
code, but rather could be SAVED as an jOrgan Console type configuration file
(not to be confused with either the jOrgan console module or the jOrgan
disposition module, but rather in jOrgan abstract organ configuration files,
which once present, are always present (until deleted) and can be re-used
for different dispositions with the same 'abstract' organ layout. A new
disposition requiring a new abstract organ would come configured for that
organ, but also have a descriptor file (perhaps XML) that would describe
that new 'standard' abstract organ, to which both future jOrgan dispositions
modules and jOrgan Keyboard console modules can conform.*

For example, very rarely a disposition creator will find a need for a new
abstract organ - e.g. a superauthentic jOrgan disposition might require a
Ruckpositive console conceptually located behind the organist bench, in
which case, this previously not-considered 'standard' disposition would be
created and documented as above in the abstract organ console configuration.
In actuality, most users would not have such a physical setup, but in their
jOrgan console setup they could decide how to implement this extra console.
Those poor users unfortunate enough not to have 5 manuals in front of them
and one manual in back of them, would be forced to reassign said new
abstract Ruckpositive to one of their actual hardware keyboards in the
jOrgan console module.

What I am proposing (and I think Rick) is some method analogous to
"Normalization" of database information - reentering the same data over and
over is not only waste of resources, but error prone.

*The only semi-new idea here (at least to me) is that these two independent
modules would rely on a third set of files, the 'virtual abstract organ'
description configuration modules. These 'virtual abstract organ'
description files would not be completely tied to any particular disposition
or hardware. They would simply be convenient defaults that the disposition
creator could reference and users configure their hardware for:

e.g.
2man1ped.xml (two manual organ consoles with pedal)
3man1ped.xml (three manual organ consoles with pedal
etc

best,

Dell


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463752.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Tom Karches
2011-04-20 18:27:06 UTC
Permalink
An excellent proposal, Standardize the inputs needed for a basic
setup, then allow the end user to change them as needed.

--tom
Post by DellAnderson
Bernd and Geert and Rick and all,
If I understand correctly what Rick is proposing, I think it is very close
(if not identical) to my description.
1)  that most users have a limited number of physical consoles, and it is
fairly annoying to have to reconfigure ALL the settings for each new version
of a disposition (worth it, but somewhat tedious).
2)  most dispositions are ideally suited for only one or two standard
console configurations (usu. 1,2, or 3 manuals + pedals).   If it is a
harpsichord, it is usually 1 or 2 manuals (unless a pedal harpsichord) etc.
These basic 'abstractions' could be standardized and more developed as
needed in a wiki-like fashion (and documented on the Wiki page under
'disposition creation' or context help files in jOrgan (if there are some).
--
Tom Karches
***@gmail.com
orgel jeux
2011-04-20 18:29:28 UTC
Permalink
Dell, you said it better that I can; but its the basic idea that I share
with you.

Not only is it the logical step, but it will also improve jOrgan's
successful use for the less-techincal user.

Thanks for spending the time to write it down so carefully!

Greeetings,

Geert
Post by DellAnderson
Bernd and Geert and Rick and all,
If I understand correctly what Rick is proposing, I think it is very close
(if not identical) to my description.
1) that most users have a limited number of physical consoles, and it is
fairly annoying to have to reconfigure ALL the settings for each new version
of a disposition (worth it, but somewhat tedious).
2) most dispositions are ideally suited for only one or two standard
console configurations (usu. 1,2, or 3 manuals + pedals). If it is a
harpsichord, it is usually 1 or 2 manuals (unless a pedal harpsichord) etc.
These basic 'abstractions' could be standardized and more developed as
needed in a wiki-like fashion (and documented on the Wiki page under
'disposition creation' or context help files in jOrgan (if there are some).
Ideally, this would not require any change in the actual jOrgan Console
code, but rather could be SAVED as an jOrgan Console type configuration file
(not to be confused with either the jOrgan console module or the jOrgan
disposition module, but rather in jOrgan abstract organ configuration files,
which once present, are always present (until deleted) and can be re-used
for different dispositions with the same 'abstract' organ layout. A new
disposition requiring a new abstract organ would come configured for that
organ, but also have a descriptor file (perhaps XML) that would describe
that new 'standard' abstract organ, to which both future jOrgan dispositions
modules and jOrgan Keyboard console modules can conform.*
For example, very rarely a disposition creator will find a need for a new
abstract organ - e.g. a superauthentic jOrgan disposition might require a
Ruckpositive console conceptually located behind the organist bench, in
which case, this previously not-considered 'standard' disposition would be
created and documented as above in the abstract organ console
configuration.
In actuality, most users would not have such a physical setup, but in their
jOrgan console setup they could decide how to implement this extra console.
Those poor users unfortunate enough not to have 5 manuals in front of them
and one manual in back of them, would be forced to reassign said new
abstract Ruckpositive to one of their actual hardware keyboards in the
jOrgan console module.
What I am proposing (and I think Rick) is some method analogous to
"Normalization" of database information - reentering the same data over and
over is not only waste of resources, but error prone.
*The only semi-new idea here (at least to me) is that these two independent
modules would rely on a third set of files, the 'virtual abstract organ'
description configuration modules. These 'virtual abstract organ'
description files would not be completely tied to any particular disposition
or hardware. They would simply be convenient defaults that the disposition
e.g.
2man1ped.xml (two manual organ consoles with pedal)
3man1ped.xml (three manual organ consoles with pedal
etc
best,
Dell
--
http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463752.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
DellAnderson
2011-04-20 18:38:20 UTC
Permalink
Here's a graphic of what I have imagined. Feel free to improve:
Loading Image...

best,

Dell


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463827.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Rick (greenfox)
2011-04-20 21:05:01 UTC
Permalink
This is beautiful Dell. Yes, we are on the exact same wave length.

Regards
Rick
Post by DellAnderson
http://jorgan.999862.n4.nabble.com/file/n3463827/ProposedJOrganModularity.png
best,
Dell
DellAnderson
2011-04-20 21:22:26 UTC
Permalink
Thanks, Rick. I hope it is possible to program this way. It is only a
proposed dream concept which no doubt is possible, but we must defer to the
master on how much programming or how long it would take given Sven's very
busy schedule.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3464187.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Marco Francesco
2011-04-21 01:51:20 UTC
Permalink
Yes, yes, yes.... I would like that! Bravo guys! I would vote in favour.

Marco

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3464732.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
BCA
2011-04-21 07:39:45 UTC
Permalink
I still think here are two different things mixed up.

- lazy guys idea: an imagination for having ONE default console setting
fitting ALL (or most of all) dispositions automatically. As I explained
earlier, this would depend on a standard console hardware principle.

- differentiated idea: an imagination for disposition-depending console
setup masks, where ONE console mask fits only ONE particular disposition.
This mask file comes with the disposition, and can be altered by the user,
and can be used for upgrades of that particular disposition.

Personally, I'd prefer the second one. Here the user has to adapt the
console mask for ONE particular disposition ONCE. This approach guarantees
the most versality of that principle.

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3465311.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
BCA
2011-04-21 09:25:23 UTC
Permalink
This would be MUCH simpler and highly flexible.
Regards
Bernd.

Loading Image...


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3465475.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Matt Pestle
2011-04-21 10:40:45 UTC
Permalink
I have given thought to building the following web application for the community:

- Disposition developers upload their disposition file
- Users download it and modify it according to their needs
- Users upload the resulting modified disposition
- the application then notes which things have been altered specific to the user's version
- subsequent versions released by the disposition developer are uploaded
- users can download these later versions, with their specific alterations inserted

This initially seemed to be a straightforward process, accomplished by pretty simple XML transformations noting the various XML nodes involved and their relationships to the elements in a disposition.

That is, it's reasonably straightforward until you start trying to take into account all of the things that could be modified by the user, and by the disposition developer moving from version 1.1 to 1.2.

If it were only restricted to devices and keypress events and toggles and simple things, then it might be OK. But I, for example, have my touchscreen in portrait mode, so I generally have to completely rearrange things to fit. So do I try to maintain positions on screen? Not being an organist, I also like to add a "Bass" coupler. Do I try to maintain that addition across disposition upgrades? I generally add fluidsynth reverb if necessary. Do I try to bring that across too?

On top of that, there are many, many ways that a disposition can change between a disposition developer's releases, and it would be very easy for Version 1.2 to *appear* nearly identical to 1.1 and yet still be almost impossible to accomplish the process above.

There are many other difficult things to think about, and doubtless there are countless more that I have never even thought about.

Ultimately, it ended up in the 'too hard' basket - In the amount of time that I spent thinking about it, I could have changed dozens of dispositions to suit my physical console. It's not actually that hard to change a disposition, and it keeps getting easier with each version released.

If anyone with more experience looking at dispositions can "well-define" the problem in terms of XML, I'm happy to write the transformation code (that's the easy part). But being able to well-define the problem in terms of XML will be essential to resolving this, since the solution must ultimately adjust the XML. My guess is there's only one person out there currently who could do that, and his silence is noteworthy.

Cheers,
Matt
DellAnderson
2011-04-21 15:20:30 UTC
Permalink
Matt,

Interesting idea. If I understood it correctly, it might work. It feels
like a 'work-around' and likely to result in something of a cacophony of
variations on dispositions, but absent a more elegant approach preserving
the disposition itself, and separating out the console configuration, your
idea might be workable. Personally, I would prefer a simple way to create a
set of standard consoles (there really are not THAT many organ console
types) as in my first scheme.

best,

Dell

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466183.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
BCA
2011-04-21 15:36:25 UTC
Permalink
Hi Matt,

I agree. A global default setup seems like trying to keep all the
mouseclicks jOrgan just is designed for, a "contradiction in terms".

WHICH parametres should be integrated into such a configuration file.

AFAICS those are only the channels for the keyboards, and perhaps the
settings for combination buttons. Already those may be an issue, since some
combination configurations base on MIDI messages, and some on keyboard
shortcuts, and some may base on things I never could imagine.

Finally, we'll come up with keyboard channels only, I'd assume.

This is because I suggested to bind a config file to the particular
disposition, and allow importing the settings into upgraded dispositions.
Even this may be superfluous, from a certain point of view.

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466231.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
DellAnderson
2011-04-21 16:16:13 UTC
Permalink
A global default setup seems like trying to keep all the mouseclicks
jOrgan just is designed for, a "contradiction in terms".
Bernd,

As an end user only, I highly respect your internal knowledge as disposition
creator, which is perhaps why I sense we are talking past each other.

However, I think you may be missing the point of my suggestion, probably
because it is not clear enough. Basically, I am NOT suggesting
dispositions come with default settings necessarily. What I AM suggesting,
is separating the configuration for the hardware from the configuration for
the disposition so that the end user only has to do the hardware
configuration ONCE and only ONCE (even from different dispositions).

This should not involve any more work for disposition creators - the
additional 'abstract organ' layer would simply stand in for the current
'real hardware' organ, which now would be covered by the end user.

I'm probably overlooking something huge, but I cannot imagine what it may be
- unless dispositions are not what I imagine them to be (I imagine that
currently dispositions are basically 'default' sound font configurations
including elements like combination actions etc in a nice GUI)....
Configuring these 'default' dispositions for a 'standard' abstract organ
definition should be easier, if anything, for disposition creators, as they
don't have to worry about things like how the end user will implement it on
a micromanaged level.

Sorry if I am way off here, but hopefully this will clarify what I am trying
to say.

best,

Dell

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466326.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Lynn Walls
2011-04-21 16:44:13 UTC
Permalink
Dell,

You're on the right track!

Here's is an EXAMPLE of how it might work, in order to illustrate the benefit to the
disposition developer:

1. Developer creates an organ definition and names it "My Big Organ". In this disposition
he defines three manuals, one pedalboard and two swells. He names them arbitrarily to be:
a. "manual_1"
b. "manual_2"
c. "manual_3"
d. "pedals"
e. "swell_1"
f. "swell_2"

These may be any names that the disposition developer desires -- hopefully better names
than I used in the above example. Likewise, names of Stop, Coupler, and Trem switches
could also be named in order to allow the virtual organ to be controlled from a physical
console that has MIDI encoders for all those switches...but that would just complicate
this example.

2. Then the disposition developer saves his creation, and it will be named "My Big
Organ.disposition".

3. Then the disposition developer makes this file available to all his friends.

4. The user downloads the file "My Big Organ.disposition", and installs it in his local
disposition folder.

5. The user starts jOrgan and opens "My Big Organ.disposition".

6. jOrgan sees that there is no hardware configuration for this disposition, so it
launches the configuration wizard and helps the user make the associations between his
physical hardware devices, channels, and MIDI commands and the abstract names listed in
step #1 above.

7. When all the disposition names have been "connected" to real hardware devices,
channels, and commands, jOrgan saves this configuration under the file name: "My Big
Organ.config" (or something similar that ties the .config file to the .disposition file).

8.
DellAnderson
2011-04-21 16:54:31 UTC
Permalink
Thanks Lynn,

Glad to hear I'm understanding both ideas. I guess my suggestion is just a
bit too cutting edge for now (I am confident it will eventually be
implemented on organ software, if not jOrgan, at least some other VPO.

I was hoping that now since there were at least a dozen dispositions, and
some user these dispositions on multiple hardware consoles (e.g. when
schlepping the laptop to another midi controller), the user wouldn't have to
reconfigure each time for each and every new disposition-hardware
combination tried.

I suppose I am being very lazy, but isn't that the job of a computer
programmer, to make things as simple, easy, and 'lazy' for the user as
possible?

best,

Dell

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466400.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
DellAnderson
2011-04-21 16:58:21 UTC
Permalink
Lynn & Bernd,

After re-reading, it sounds like your solutions only solves one tiny little
problem - making it so one doesn't have to reconfigure a given disposition
after each update. Provided one does not 1) change to a different
disposition or 2) change to a different hardware console.

Frankly, I don't understand why disposition creators cannot solve that
problem already.

The problem to which I am trying to propose a solution has more to do with
separating the concept of the hardware from the software, which should not
be all that difficult, and would reap HUGE benefits when experimenting with
various dispositions or changing hardware consoles.

I honestly think we are talking at completely different conceptual
altitudes.

best,

Dell


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466411.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
BCA
2011-04-21 17:09:09 UTC
Permalink
Hi Dell,

before we can discuss seemingly different approaches: please list (if
possible exactly), which disposition parametres your concept shall store.

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466441.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Lynn Walls
2011-04-21 17:25:44 UTC
Permalink
Yes...my two-layer (disposition file/config file) solution is essentially intended to help
the disposition developer --- NOT the end user. There would have to be a .config file
tailored to each unique disposition. That is necessary because each disposition would
potentially have a different number of keyboards, a different number of swells, and a
different number of stops, couplers, trems and any other switches. It would not be
feasible to define all these objects with any sort of "standard" nomenclature. Just for
example, the manuals in classical/church organ terminology are named completely
differently than those of a theatre organ. And even within each of those classes of organ
the nomenclature often varies. And what about harpsichords, and electronic synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan can potentially
support? Don't assume that jOrgan is only only for pipe organs. So don't try to come up
with some "standard" that only addresses pipe organs. Simply put: just leave it up to the
disposition developer to name those input and output devices in the most meaningful way so
that when the Configuration WIZARD presents those names to the end user, that end user
will know what physical device needs to be connected to that name.

It is the robustness of the WIZARD that will help the "lazy" end user -- NOT the layered
disposition/config file architecture.

You'll never get anywhere with trying to make it simpler for the end user that a good
configuration WIZARD. Face it: at a MINIMUM, the end user will HAVE to understand his
MIDI hardware, and he will HAVE to go through a configuration process at least ONCE per
different organ definition disposition. Even Hauptwerk does not make it simpler than
this! In fact, Hauptwerk's configuration wizard could probably be used as a functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the scope,
channel and device of every keyboard and continuous controller (swell).

Any user who wants to be "lazier" than this probably does not deserve much consideration
from this forum. If Sven were trying to make money from selling jOrgan licenses, he might
be inclined to bend-over-backwards for the ultra-lazy dummy. But given the monetary
compensation involved, I would be surprised if any serious help would be forthcoming for
any end user who is unwilling to work through a configuration wizard at least once for
each distinct disposition that he wants to use.

CLW
------------------------------------------------------------------------
Lynn& Bernd,
After re-reading, it sounds like your solutions only solves one tiny little
problem - making it so one doesn't have to reconfigure a given disposition
after each update. Provided one does not 1) change to a different
disposition or 2) change to a different hardware console.
Frankly, I don't understand why disposition creators cannot solve that
problem already.
The problem to which I am trying to propose a solution has more to do with
separating the concept of the hardware from the software, which should not
be all that difficult, and would reap HUGE benefits when experimenting with
various dispositions or changing hardware consoles.
I honestly think we are talking at completely different conceptual
altitudes.
best,
Dell
--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466411.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-21 18:47:33 UTC
Permalink
Any ID tags should indicate the genre, i.e., Theatre or Church
(classical/sacred), and the number of Manuals and Pedal, i.e., I/P, II/P,
III/P, IV/P and Creative Sound or Fluidsynth and if Fluidsynth, the
particulars regarding PortAudio/ASIO/ etc. It is no problem to configure a
II/P organ to play five divisions with MIDI, involving a change of
combinations via piston rather than a manual change. Probably most have
done this with some of the larger dispositions having three or more manuals.
It is the different types of Fluidsynth
configurations possible that will determine choice, but haven't most
dispositions been released to users with both a Creative Sound and a
Fluidsynth Sound version? Also, any who are familiar with jOrgan
construction mode can, if they are determined and not in violation of some
license or creator's prohibition, configure a given disposition for either
Creative or Fluidsynth according to their abilities and hardware. Those
whose professional creativity is a matter of significant historical record
and for whom it is a question of or concern for the purity of either
specification or sound-set quality may wish to release their dispositions
with such a stipulation, but given the varied output devices that are used
by members with downloadable dispositions, it seems logical to allow these
changes in the privacy of one's own music room. I have made soundfonts
having the exact presets of many of the creators' dispositions on the forum
using my own sounds just for purposes of comparison. (It's that challenge
of electronics versus the real pipe "thing.") Anyway, my humble
opinion......

John B.

-----Original Message-----
From: Lynn Walls
Sent: Thursday, April 21, 2011 1:25 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab

Yes...my two-layer (disposition file/config file) solution is essentially
intended to help
the disposition developer --- NOT the end user. There would have to be a
.config file
tailored to each unique disposition. That is necessary because each
disposition would
potentially have a different number of keyboards, a different number of
swells, and a
different number of stops, couplers, trems and any other switches. It would
not be
feasible to define all these objects with any sort of "standard"
nomenclature. Just for
example, the manuals in classical/church organ terminology are named
completely
differently than those of a theatre organ. And even within each of those
classes of organ
the nomenclature often varies. And what about harpsichords, and electronic
synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan
can potentially
support? Don't assume that jOrgan is only only for pipe organs. So don't
try to come up
with some "standard" that only addresses pipe organs. Simply put: just
leave it up to the
disposition developer to name those input and output devices in the most
meaningful way so
that when the Configuration WIZARD presents those names to the end user,
that end user
will know what physical device needs to be connected to that name.

It is the robustness of the WIZARD that will help the "lazy" end user -- NOT
the layered
disposition/config file architecture.

You'll never get anywhere with trying to make it simpler for the end user
that a good
configuration WIZARD. Face it: at a MINIMUM, the end user will HAVE to
understand his
MIDI hardware, and he will HAVE to go through a configuration process at
least ONCE per
different organ definition disposition. Even Hauptwerk does not make it
simpler than
this! In fact, Hauptwerk's configuration wizard could probably be used as a
functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect
the scope,
channel and device of every keyboard and continuous controller (swell).

Any user who wants to be "lazier" than this probably does not deserve much
consideration
from this forum. If Sven were trying to make money from selling jOrgan
licenses, he might
be inclined to bend-over-backwards for the ultra-lazy dummy. But given the
monetary
compensation involved, I would be surprised if any serious help would be
forthcoming for
any end user who is unwilling to work through a configuration wizard at
least once for
each distinct disposition that he wants to use.

CLW
------------------------------------------------------------------------
Lynn& Bernd,
After re-reading, it sounds like your solutions only solves one tiny little
problem - making it so one doesn't have to reconfigure a given disposition
after each update. Provided one does not 1) change to a different
disposition or 2) change to a different hardware console.
Frankly, I don't understand why disposition creators cannot solve that
problem already.
The problem to which I am trying to propose a solution has more to do with
separating the concept of the hardware from the software, which should not
be all that difficult, and would reap HUGE benefits when experimenting with
various dispositions or changing hardware consoles.
I honestly think we are talking at completely different conceptual
altitudes.
best,
Dell
--
http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466411.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-21 19:03:15 UTC
Permalink
"Any user who wants to be "lazier" than this probably does not deserve much
consideration
from this forum. "

Very well put, Lynn, very forthright and to the point, although I seem to
detect a tone of frustration in the wording. I think that those to whom
this observation finds applicability
will probably think twice about letting you know that they are lazier than
pet coons and can't configure their own if they had to.

John B.
DellAnderson
2011-04-21 19:29:37 UTC
Permalink
Post by Lynn Walls
Yes...my two-layer (disposition file/config file) solution is essentially intended to help
the disposition developer --- NOT the end user. There would have to be a .config file
tailored to each unique disposition. That is necessary because each disposition would
potentially have a different number of keyboards, a different number of swells, and a
different number of stops, couplers, trems and any other switches. It would not be
feasible to define all these objects with any sort of "standard"
nomenclature.
I guess I am either completely misunderstanding the resistance to Rick & my
& others idea for abstracting out the mechanical console configuration files
from the distribution, or else Lynn and Bernd are misunderstanding what we
are trying to propose...which has nothing to do with trems or other switches
not likely to be on most hardware consoles.

Conceptually, it seems obvious to me that abstracting out the hardware would
be far more efficient and elegant programming. I cannot abide programs that
require reentry of the same data over and over which is not tied to the
change of disposition.

I think I would have to take the opponents of this rather basic concept in
person to explain it as currently there seems to be a failure of
understanding, perhaps because of long entrenched thought patterns related
to the current jOrgan configuration. What I was suggestion was NOT
revolutionary, but evolutionary. Nothing in jOrgan would have to change.
Merely separating off the portions unlikely to change frequently (such as
number of keys on your keyboard, number of pistons, number of swell and
crescendo controllers).

I think my prior posts were clear enough for anyone to understand, including
the color schematic. I will assume that all future opponents simply do not
want that, which is fine. I am not the programmer, just a user expressing a
wish.

Thanks for at least giving it the dignity of a discussion, even if there are
a few rather unusually negative opponents for unclear reasons.

I'm on my way to an organ lesson out of town, so no more posts on this topic
will be forthcoming from me...at least today!

best,

Dell

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466697.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
orgel jeux
2011-04-21 21:39:49 UTC
Permalink
Dell,

I am with you.... it is brilliant....perhaps too....-:))

Geert
Post by DellAnderson
Post by Lynn Walls
Yes...my two-layer (disposition file/config file) solution is essentially
intended to help
the disposition developer --- NOT the end user. There would have to be a .config file
tailored to each unique disposition. That is necessary because each disposition would
potentially have a different number of keyboards, a different number of swells, and a
different number of stops, couplers, trems and any other switches. It would not be
feasible to define all these objects with any sort of "standard"
nomenclature.
I guess I am either completely misunderstanding the resistance to Rick & my
& others idea for abstracting out the mechanical console configuration files
from the distribution, or else Lynn and Bernd are misunderstanding what we
are trying to propose...which has nothing to do with trems or other switches
not likely to be on most hardware consoles.
Conceptually, it seems obvious to me that abstracting out the hardware would
be far more efficient and elegant programming. I cannot abide programs that
require reentry of the same data over and over which is not tied to the
change of disposition.
I think I would have to take the opponents of this rather basic concept in
person to explain it as currently there seems to be a failure of
understanding, perhaps because of long entrenched thought patterns related
to the current jOrgan configuration. What I was suggestion was NOT
revolutionary, but evolutionary. Nothing in jOrgan would have to change.
Merely separating off the portions unlikely to change frequently (such as
number of keys on your keyboard, number of pistons, number of swell and
crescendo controllers).
I think my prior posts were clear enough for anyone to understand, including
the color schematic. I will assume that all future opponents simply do not
want that, which is fine. I am not the programmer, just a user expressing a
wish.
Thanks for at least giving it the dignity of a discussion, even if there are
a few rather unusually negative opponents for unclear reasons.
I'm on my way to an organ lesson out of town, so no more posts on this topic
will be forthcoming from me...at least today!
best,
Dell
--
http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466697.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
BCA
2011-04-22 07:24:42 UTC
Permalink
Hi,

during a good nights rest, I came to the conclusion I'll propose to Sven a
"Save/Load" ability for the COSTUMIZER.

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3467536.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Jonathan Aquilina
2011-04-21 17:13:34 UTC
Permalink
Your last paragraph is exactly what i was getting at when i suggested a
sound font editor as part of jorgan. Making it easier for the
disposition editors to work in one program with out having to have 5
different applications open to achieve this same goal.
Post by DellAnderson
Thanks Lynn,
Glad to hear I'm understanding both ideas. I guess my suggestion is just a
bit too cutting edge for now (I am confident it will eventually be
implemented on organ software, if not jOrgan, at least some other VPO.
I was hoping that now since there were at least a dozen dispositions, and
some user these dispositions on multiple hardware consoles (e.g. when
schlepping the laptop to another midi controller), the user wouldn't have to
reconfigure each time for each and every new disposition-hardware
combination tried.
I suppose I am being very lazy, but isn't that the job of a computer
programmer, to make things as simple, easy, and 'lazy' for the user as
possible?
best,
Dell
--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466400.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-21 18:57:30 UTC
Permalink
Other than the fact that saving a disposition in a later version of jOrgan
upgrades it so that it is NOT backward compatible with previous versions of
jOrgan, is there a reason why
the version number is stored in the body of the XML disposition? I have
folders with the last 4 betas of 3.13 and I am careful to keep them
separate, always remembering to open jOrgan by version number then opening
the disposition which is in that specific folder. If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.

John B.
Rick (greenfox)
2011-04-23 11:06:40 UTC
Permalink
John

This "default 3.12" you mention is only on YOUR system.

When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".

In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.

This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.

I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.

Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
John Beach
2011-04-23 11:28:55 UTC
Permalink
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).

John

-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab

John

This "default 3.12" you mention is only on YOUR system.

When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".

In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.

This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.

I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.

Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
Lynn Walls
2011-04-23 14:28:46 UTC
Permalink
Rick and John,

You are discussing two different things here:

1. Rick: .disposition association to executable jOrgan version.

2. John: Registry memory of last .disposition folder used. (jOrgan "remembers" in the
Windows Registry the folder where it last opened a .disposition file without regard to
which version of the jOrgan executable has been launched. I don't know how this works in
a non-Windows o/s.) This is not a jOrgan "bug", but rather a design point of jOrgan
(which I personally find to be a nuisance).

John, the way I avoid having the launch of an OLDER version of jOrgan pick up a LATER
version of a .disposition is to either explicitly code the full path of the .disposition
file on the command line of the desktop shortcut, or navigate to the correct disposition
folder with the file-open dialog window.

CLW
-----------------------------------------------------------------------
Post by John Beach
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).
John
-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles"& "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
John
This "default 3.12" you mention is only on YOUR system.
When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".
In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.
This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.
I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.
Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Jonathan Aquilina
2011-04-23 14:57:22 UTC
Permalink
There is something i have noticed which is rather a show stopper in my
opinion. i had 3.12.3 installed on windows 7 64bit, when i came to
install 3.13 beta 7 it basically overwrote my 3.12.3 installation, is
that a bug? Is it possible to be able to install multiple versions of
jorgan side by side? Also anyone else experiencing this on win 7 64bit?
Post by Lynn Walls
Rick and John,
1. Rick: .disposition association to executable jOrgan version.
2. John: Registry memory of last .disposition folder used. (jOrgan "remembers" in the
Windows Registry the folder where it last opened a .disposition file without regard to
which version of the jOrgan executable has been launched. I don't know how this works in
a non-Windows o/s.) This is not a jOrgan "bug", but rather a design point of jOrgan
(which I personally find to be a nuisance).
John, the way I avoid having the launch of an OLDER version of jOrgan pick up a LATER
version of a .disposition is to either explicitly code the full path of the .disposition
file on the command line of the desktop shortcut, or navigate to the correct disposition
folder with the file-open dialog window.
CLW
-----------------------------------------------------------------------
Post by John Beach
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).
John
-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles"& "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
John
This "default 3.12" you mention is only on YOUR system.
When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".
In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.
This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.
I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.
Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Lynn Walls
2011-04-23 15:15:19 UTC
Permalink
The jOrgan Windows installer defaults to installing the new version of jOrgan in the same
folder where jOrgan was last installed. It DOES give you the option of overriding this
folder during the install process. If you FAIL to override the install directory at the
point where it gives you this option, the new version will be installed over the most
recently installed version.

CLW
-----------------------------------------------------------------------------
Post by Jonathan Aquilina
There is something i have noticed which is rather a show stopper in my
opinion. i had 3.12.3 installed on windows 7 64bit, when i came to
install 3.13 beta 7 it basically overwrote my 3.12.3 installation, is
that a bug? Is it possible to be able to install multiple versions of
jorgan side by side? Also anyone else experiencing this on win 7 64bit?
Post by Lynn Walls
Rick and John,
1. Rick: .disposition association to executable jOrgan version.
2. John: Registry memory of last .disposition folder used. (jOrgan "remembers" in the
Windows Registry the folder where it last opened a .disposition file without regard to
which version of the jOrgan executable has been launched. I don't know how this works in
a non-Windows o/s.) This is not a jOrgan "bug", but rather a design point of jOrgan
(which I personally find to be a nuisance).
John, the way I avoid having the launch of an OLDER version of jOrgan pick up a LATER
version of a .disposition is to either explicitly code the full path of the .disposition
file on the command line of the desktop shortcut, or navigate to the correct disposition
folder with the file-open dialog window.
CLW
-----------------------------------------------------------------------
Post by John Beach
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).
John
-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles"& "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
John
This "default 3.12" you mention is only on YOUR system.
When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".
In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.
This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.
I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.
Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-23 16:04:35 UTC
Permalink
Not my problem. I always type the full version number in the install
process, i.e., C:\Program Files\jOrgan 3.13 beta 7.
I do this without fail.

John

-----Original Message-----
From: Lynn Walls
Sent: Saturday, April 23, 2011 11:15 AM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] Version Associations and such

The jOrgan Windows installer defaults to installing the new version of
jOrgan in the same
folder where jOrgan was last installed. It DOES give you the option of
overriding this
folder during the install process. If you FAIL to override the install
directory at the
point where it gives you this option, the new version will be installed over
the most
recently installed version.

CLW
-----------------------------------------------------------------------------
Post by Jonathan Aquilina
There is something i have noticed which is rather a show stopper in my
opinion. i had 3.12.3 installed on windows 7 64bit, when i came to
install 3.13 beta 7 it basically overwrote my 3.12.3 installation, is
that a bug? Is it possible to be able to install multiple versions of
jorgan side by side? Also anyone else experiencing this on win 7 64bit?
Post by Lynn Walls
Rick and John,
1. Rick: .disposition association to executable jOrgan version.
2. John: Registry memory of last .disposition folder used. (jOrgan "remembers" in the
Windows Registry the folder where it last opened a .disposition file without regard to
which version of the jOrgan executable has been launched. I don't know how this works in
a non-Windows o/s.) This is not a jOrgan "bug", but rather a design point of jOrgan
(which I personally find to be a nuisance).
John, the way I avoid having the launch of an OLDER version of jOrgan pick up a LATER
version of a .disposition is to either explicitly code the full path of the .disposition
file on the command line of the desktop shortcut, or navigate to the correct disposition
folder with the file-open dialog window.
CLW
-----------------------------------------------------------------------
Post by John Beach
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).
John
-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles"& "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
John
This "default 3.12" you mention is only on YOUR system.
When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".
In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.
This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.
I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.
Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Jonathan Aquilina
2011-04-23 16:55:11 UTC
Permalink
In all honesty i think that is bad practice in my opinion. If there are
issues with the latest version you dont have a stable version to fall
back on which is installed.
Post by Lynn Walls
The jOrgan Windows installer defaults to installing the new version of jOrgan in the same
folder where jOrgan was last installed. It DOES give you the option of overriding this
folder during the install process. If you FAIL to override the install directory at the
point where it gives you this option, the new version will be installed over the most
recently installed version.
CLW
-----------------------------------------------------------------------------
Post by Jonathan Aquilina
There is something i have noticed which is rather a show stopper in my
opinion. i had 3.12.3 installed on windows 7 64bit, when i came to
install 3.13 beta 7 it basically overwrote my 3.12.3 installation, is
that a bug? Is it possible to be able to install multiple versions of
jorgan side by side? Also anyone else experiencing this on win 7 64bit?
Post by Lynn Walls
Rick and John,
1. Rick: .disposition association to executable jOrgan version.
2. John: Registry memory of last .disposition folder used. (jOrgan "remembers" in the
Windows Registry the folder where it last opened a .disposition file without regard to
which version of the jOrgan executable has been launched. I don't know how this works in
a non-Windows o/s.) This is not a jOrgan "bug", but rather a design point of jOrgan
(which I personally find to be a nuisance).
John, the way I avoid having the launch of an OLDER version of jOrgan pick up a LATER
version of a .disposition is to either explicitly code the full path of the .disposition
file on the command line of the desktop shortcut, or navigate to the correct disposition
folder with the file-open dialog window.
CLW
-----------------------------------------------------------------------
Post by John Beach
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).
John
-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles"& "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
John
This "default 3.12" you mention is only on YOUR system.
When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".
In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.
This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.
I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.
Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Lynn Walls
2011-04-23 18:43:59 UTC
Permalink
You can always re-install the older version from its installer package. That's the easy
part. The real problem is that if you allow the NEWER version to update your .disposition
files, and you did not keep backup copies created by the older versions, then you are out
of luck...because there is presently no programmatic way of reverse engineering a newer
version or a .disposition file back to an older version.

CLW
---------------------------------------------------------------------------------------
Post by Jonathan Aquilina
In all honesty i think that is bad practice in my opinion. If there are
issues with the latest version you dont have a stable version to fall
back on which is installed.
Post by Lynn Walls
The jOrgan Windows installer defaults to installing the new version of jOrgan in the same
folder where jOrgan was last installed. It DOES give you the option of overriding this
folder during the install process. If you FAIL to override the install directory at the
point where it gives you this option, the new version will be installed over the most
recently installed version.
CLW
-----------------------------------------------------------------------------
Post by Jonathan Aquilina
There is something i have noticed which is rather a show stopper in my
opinion. i had 3.12.3 installed on windows 7 64bit, when i came to
install 3.13 beta 7 it basically overwrote my 3.12.3 installation, is
that a bug? Is it possible to be able to install multiple versions of
jorgan side by side? Also anyone else experiencing this on win 7 64bit?
Post by Lynn Walls
Rick and John,
1. Rick: .disposition association to executable jOrgan version.
2. John: Registry memory of last .disposition folder used. (jOrgan "remembers" in the
Windows Registry the folder where it last opened a .disposition file without regard to
which version of the jOrgan executable has been launched. I don't know how this works in
a non-Windows o/s.) This is not a jOrgan "bug", but rather a design point of jOrgan
(which I personally find to be a nuisance).
John, the way I avoid having the launch of an OLDER version of jOrgan pick up a LATER
version of a .disposition is to either explicitly code the full path of the .disposition
file on the command line of the desktop shortcut, or navigate to the correct disposition
folder with the file-open dialog window.
CLW
-----------------------------------------------------------------------
Post by John Beach
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).
John
-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles"& "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
John
This "default 3.12" you mention is only on YOUR system.
When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".
In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.
This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.
I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.
Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Jonathan Aquilina
2011-04-23 19:44:42 UTC
Permalink
orgel jeux
2011-04-23 20:09:01 UTC
Permalink
Lynn, I fully agree with you on the registry issue.

Although I am very careful to open the jOrgan-version I want, and load the
dipsosition form the appropriate location,

I find it not very handy that the save option does not let me save an
altered dispo under a new name NOR at the location to my choice.

So I have to change the name beforehand.

An when using a disposition that happens to have the same name as a dispo
belonging to an older version I am always fearing that it will overwrite, as
I have no influence on the saving location.

Now people might say, that I make it needless complex by having different
jOrgan versions on the same PC, and several maps with disposition files
belonging to them.
But that is my way of following the evolution, and at the same time keep
some fine working dispos together with their jOrgan versions.

greetings,

Geert

All other Windows programs do not have this peculiairity........

2011/4/23 Jonathan Aquilina <***@gmail.com>
Lynn Walls
2011-04-23 21:47:22 UTC
Permalink
The one that REALLY confuses me is the jOrgan Recorder. After I record something, I never
know if I am overwriting a previously loaded recording that I did not want damaged. I am
never really sure what file name I am saving the new recording as.

Afer a few "safety" renames of MIDI files that I don't want to lose, and a few trials, I
eventually figure it out. But the way it works is NOT intuitive and not conventional. I
wish it worked something like this:

When recording...
1. Force the Reorder to be "armed" by requiring the user to
explicitly specify the file name to save the recording into.
2. Record one or more takes with the Recorder.
3. Save the last recording take into the file named in #1 above,
or allow an override of that file name with another "save as"
name entered into the "Save" dialog.

When playing...
1. Require a "Load" function to "arm" the Player that loads any available
jOrgan MIDI file.
2. Play that file as many times as desired.
3. Do not allow the Record function to overlay the last played file,
forcing the user to have to explicitly re-Arm the Recorder with a
specific file name before a recording can be made.

CLW
--------------------------------------------------------------------
Post by orgel jeux
Lynn, I fully agree with you on the registry issue.
Although I am very careful to open the jOrgan-version I want, and load the dipsosition
form the appropriate location,
I find it not very handy that the save option does not let me save an altered dispo under
a new name NOR at the location to my choice.
So I have to change the name beforehand.
An when using a disposition that happens to have the same name as a dispo belonging to an
older version I am always fearing that it will overwrite, as I have no influence on the
saving location.
Now people might say, that I make it needless complex by having different jOrgan versions
on the same PC, and several maps with disposition files belonging to them.
But that is my way of following the evolution, and at the same time keep some fine working
dispos together with their jOrgan versions.
greetings,
Geert
All other Windows programs do not have this peculiairity........
Jonathan Aquilina
2011-04-24 05:09:27 UTC
Permalink
Orgel i +1 my concerns for this issue as well. Also thinking about it in
regards to upgrading dispositions why not have it create a new folder
and throw an upgraded version of the disposition in a seperate folder
Post by orgel jeux
Lynn, I fully agree with you on the registry issue.
Although I am very careful to open the jOrgan-version I want, and
load the dipsosition form the appropriate location,
I find it not very handy that the save option does not let me save an
altered dispo under a new name NOR at the location to my choice.
So I have to change the name beforehand.
An when using a disposition that happens to have the same name as a
dispo belonging to an older version I am always fearing that it will
overwrite, as I have no influence on the saving location.
Now people might say, that I make it needless complex by having
different jOrgan versions on the same PC, and several maps with
disposition files belonging to them.
But that is my way of following the evolution, and at the same time
keep some fine working dispos together with their jOrgan versions.
greetings,
Geert
All other Windows programs do not have this peculiairity........
Rick (greenfox)
2011-04-24 12:42:18 UTC
Permalink
/"An when using a disposition that happens to have the same name as a
dispo belonging to an older version I am always fearing that it will
overwrite, as I have no influence on the saving location."/

jOrgan will only ever save a disposition file in the folder it opened it in.

The easiest thing to do to create a new copy disposition, is to create a
folder containing the .disposition file, the .memory file, any
associated soundfont files (if used) and .mid files (if used). These
can all use simple file name addressing in the disposition as they all
reside in the same folder as the .disposition file.
It is then a simple matter to copy the folder, rename the folder and
rename the .disposition in the folder. You now have a complete copy of
a working jOrgan disposition (and all its associated files).

You must decide what you are intending to do before you open a
disposition. Once a disposition is open your only options are either to
not save any changes, or to save changes using the existing file name
(and position).

Regards
Rick
John Beach
2011-04-23 16:00:53 UTC
Permalink
Lynn, I was merely documenting a point of fact for Rick, that, if I open
the 3.13 beta 7 folder of jOrgan and click on a disposition INSTEAD of
opening the jOrgan version 3.13 beta 7 by use of the shortcut icon on the
desktop, the disposition on which I clicked in the 3.13 beta 7 disposition
folder would cause jOrgan version 3.12 to open and inform of the fact that
the disposition file which I was attempting to open was not a valid jOrgan
disposition. This occurs because the disposition has been updated and saved
in the later version of jOrgan, and, once saved, it is not BACKWARD
compatible with previous versions of jOrgan. Why clicking on any
disposition IN any of the folders of the five separate versions of jOrgan
which I have installed on Windows 7 (and for which there are separate
shortcut icons on the desktop) causes jOrgan version 3.12 to open, by
default, I do not know. This is NOT a standard practice anyway, I usually
click the desktop icon and open the version of jOrgan that I want. I
usually only keep about two versions installed, the latest stable release
and the current beta. But recently betas have been released so frequently
that I did not want to delete versions to which I had COPIED dispositions
and updated and SAVED to the most recent beta version. So, I have 3.12
FINAL and that is the version that opens by default if I click on a
disposition file in any of the other installed versions of jOrgan. As I
said, I don't know why this occurs because I have checked the "Associate
Dispositions" box on installing. Perhaps jOrgan is suffering from
Multiple-Version Disorder and, if more than one version has been installed
with the "Associate Dispositions" box checked for that version, jOrgan
version X simply does not know what to do with jOrgan version Y's
disposition.

Hilfe, Hilfe, Herr Doktor Sven, Meine Frau ist ganz verrueckt und dies ist
mittens KettenReaktion geschehen! Was mache Ich nun?

John

-----Original Message-----
From: Lynn Walls
Sent: Saturday, April 23, 2011 10:28 AM
To: jorgan-***@lists.sourceforge.net
Subject: [jOrgan-user] Version Associations and such (was: PROPOSAL: "jOrgan
Consoles" & "jOrgan Dispositions" module abstractions separation)

Rick and John,

You are discussing two different things here:

1. Rick: .disposition association to executable jOrgan version.

2. John: Registry memory of last .disposition folder used. (jOrgan
"remembers" in the
Windows Registry the folder where it last opened a .disposition file without
regard to
which version of the jOrgan executable has been launched. I don't know how
this works in
a non-Windows o/s.) This is not a jOrgan "bug", but rather a design point
of jOrgan
(which I personally find to be a nuisance).

John, the way I avoid having the launch of an OLDER version of jOrgan pick
up a LATER
version of a .disposition is to either explicitly code the full path of the
.disposition
file on the command line of the desktop shortcut, or navigate to the correct
disposition
folder with the file-open dialog window.

CLW
-----------------------------------------------------------------------
Post by John Beach
That is not correct, Rick. On installing 3.13 beta 7, I checked "Associate
disposition files" and it still defaults to 3.12. I don't know if this has
something to do with its being
the current stable release of the program, Sven would know. I keep
shortcuts to all the installed versions of jOrgan on the desktop,
individually numbered by their release names. But if I were to click on a
disposition file in the 3.13 beta 7 folder, it is jOrgan version 3.12
installed on 12/24/10 that will open and inform me that the file is not a
valid jOrgan disposition (since it has been upgraded and saved in version
3.13 beta 7).
John
-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 7:06 AM
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles"& "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
John
This "default 3.12" you mention is only on YOUR system.
When you installed jOrgan V3.12 you must have selected the following
function in the installation. On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".
In newer installations you have not selected this. If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.
This is not an error or fault in jOrgan. It is just that you have not
understood the results of selections you have made in various
installations. Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file. It is
only as smart as the last time the installation told Windows to update
the association.
I agree it is a trap. (The latest versions now warn you they are going
to update your file) The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program. If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program. If you develop this habit you will not get caught.
Regards
Rick
Post by John Beach
If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION," which, of course, it not true. It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-23 16:17:43 UTC
Permalink
When the question of "associate dispositions with this version of jOrgan" is
presented on installation, does that mean associate the dispositions located
in previously installed versions of jOrgan with the version currently being
installed? Or, does that mean associate the dispositions that are in the
folder of the currently-being installed version of jOrgan with the
currently-being installed version of jOrgan?
Does jOrgan actually do a "search" and identify disposition files in
previously installed versions to find out what to associate?

John
Graham Goode
2011-04-23 16:27:38 UTC
Permalink
Hi John,

It should mean that any .disposition file will be opened by the
jorgan.exe that is to be installed by that installer... so clicking on
any .disposition file after installing that jOrganwill load the
jorgan.exe just installed.

jOrgan does not care where the .disposition file is, as this is a
Windows 'association' feature. All .disposition files will be
associated as it is the file extension that Windows associates with an
executable.

The 'last opened disposition' is also an issue as this is stored in
the registry and will be presented to any jorgan.exe that is run,
regardless of the version. Again, this is a Windows issue.

GrahamG
Post by John Beach
When the question of "associate dispositions with this version of jOrgan" is
presented on installation, does that mean associate the dispositions located
in previously installed versions of jOrgan with the version currently being
installed? Or, does that mean associate the dispositions that are in the
folder of the currently-being installed version of jOrgan with the
currently-being installed version of jOrgan?
Does jOrgan actually do a "search" and identify disposition files in
previously installed versions to find out what to associate?
John
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Dan Dietzer
2011-04-23 16:27:49 UTC
Permalink
The "association" is a function of the Windows operating system. The
registry contains a list of file extensions and the associated command
to execute against the file. For example, an extension of ".txt" is
associated with "Notepad.exe".

If you select the "associate disposition," then any file with an
extension of ".disposition" will be opened with "jOrgan.exe".

Regards,
Dan
Post by John Beach
When the question of "associate dispositions with this version of jOrgan" is
presented on installation, does that mean associate the dispositions located
in previously installed versions of jOrgan with the version currently being
installed? Or, does that mean associate the dispositions that are in the
folder of the currently-being installed version of jOrgan with the
currently-being installed version of jOrgan?
Does jOrgan actually do a "search" and identify disposition files in
previously installed versions to find out what to associate?
John
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-23 17:23:10 UTC
Permalink
This is NOT a problem for me. I accept the disclaimers that come with all computer software. If you have any problems, I AM NOT RESPONSIBLE FOR ANY OF YOUR PROBLEMS! PERIOD!
END OF DISCUSSION!

I am aware of file “open with” program associations. The fact is that if there are five jOrgan.exes (plural) installed, it is not JUST a Windows issue, unless Windows updates the “association” of disposition files from previously installed jOrgan.exe files which had that association of dispositions. In other words, upon installation of a new jOrgan.exe, Windows disassociates dispositions from the previously-associated version of the .exe to the newer .exe. I do regular cleanings of the registry, so there should be no problem from that standpoint.
For purposes of confirmation, I just deleted 3.13 beta 7 (placing a copy of the dispositions folder on the desktop during re-installation and putting it back in the jOrgan 3.13 beta 7 folder after newly installing) and associated dispositions with 3.13 beta 7 on installing. After putting the dispositions folder back in the jOrgan program folder, I clicked on a disposition and
jOrgan 3.12 Final opened. So “associate dispositions” is NOT making a change in association from one version to the next, confirming what I suspected all along. In the words of William Shakespeare, “That which we know as a rose by ANY OTHER NAME” is still a rose.” So, unless two or more exe files of the same program are specified as different versions, Windows
does not discriminate and sees 3.12 (exe )as the valid opener of any disposition regardless of whether 3.13 beta 7 (exe) ”believes” that a certain disposition is its property!
What Windows sees is what Windows gets.
John B.
From: Dan Dietzer
Sent: Saturday, April 23, 2011 12:27 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] Version Associations and such

The "association" is a function of the Windows operating system. The registry contains a list of file extensions and the associated command to execute against the file. For example, an extension of ".txt" is associated with "Notepad.exe".

If you select the "associate disposition," then any file with an extension of ".disposition" will be opened with "jOrgan.exe".

Regards,
Dan

On 4/23/2011 12:17 PM, John Beach wrote:
When the question of "associate dispositions with this version of jOrgan" is
presented on installation, does that mean associate the dispositions located
in previously installed versions of jOrgan with the version currently being
installed? Or, does that mean associate the dispositions that are in the
folder of the currently-being installed version of jOrgan with the
currently-being installed version of jOrgan?
Does jOrgan actually do a "search" and identify disposition files in
previously installed versions to find out what to associate?

John


------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user


--------------------------------------------------------------------------------
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails


--------------------------------------------------------------------------------
Rick (greenfox)
2011-04-24 01:07:11 UTC
Permalink
Hello again John.

I apologise if it seemed I was telling you what you already knew. I was
commenting on the symptom, not aware of the steps you had taken to get
there.
John Beach
2011-04-24 09:28:03 UTC
Permalink
If I open a disposition with XML Notepad, on the right it says "version 1.0"
and immediately below that it gives the jOrgan version, "3.12" in the case
of 3.12 final and "3.13 beta 7" in the case of a disposition that was
upgraded and saved in 3.13 beta 7. In BOTH cases, it states "version 1.0"
which must be the XML version and may not have anything to do with jOrgan in
particular.
I know that a shortcut icon relates specifically to a program version by
properties>target>drive>path, so two or more .exe files of the same
application or program ARE distinguished at least by the linkage of
target>drive>path. I don't believe Windows suffers from dysfunction because
there are more than one .exe file of jOrgan and it can't determine which of
the two or more .exe files it is supposed to open. They are either
installed as identifiably separate entities or they are overwritten by the
newer installation. Unless I am reinstalling an application with the same
folder name and my intention is to overwrite the existing installation to
correct a problem, I install the application in a folder with its version
number because I need to see it and I don't worry about Windows because I
think it treats everything as an individually identifiable object, to the
point where it numbers in parentheses files which are the same but of which
there are more than one. No need to apologise. Sometimes it is difficult
to accurately describe a given problem. As I said, I keep jOrgan shortcuts
on the desktop and use those to open jOrgan FIRST and then go to the
disposition folder in THAT version and open it. Why clicking on a
disposition in the 3.13 b7 disposition folder, which has been upgraded and
saved in 3.13 b7, would cause the 3.12 jOrgan.jar to run is what I don't
understand......unless there is some identifier that is "pinged" within the
disposition file itself that tells either the Java environment or Windows
that a specific jOrgan version is required to run that particular
disposition file. I have deleted all the versions except the stable 3.12
and 3.13 b7 from C: drive.
Interestingly, C: drive has "Program Files" Program Files (X86)"
"ProgramData" folders. In Windows Explorer, if I look at C: drive>Program
Files> there are those two versions of jOrgan.
I have a music sequencer program called "Record Producer Deluxe". It opens
.mid files and has an Audio Editor Window that opens wave and mp3 files. If
I navigate to C: drive using the File>Open function in Record Producer
Deluxe, INSPITE of the fact that I have deleted the other versions of jOrgan
from the hard drive, I am shown ALL the older versions of jOrgan in
folders with a little padlock which were at one time installed. I don't
know why there is this phenomenon AFTER deleting them from C drive. Why
would an application have folders that don't exist? I think the padlock
folder represents a backup folder, but I don't know why this one program
would continue to show folders that I can not navigate to in Windows
Explorer because they have been deleted. I suppose there is a principle
here somewhere but I am not entirely sure what to do about it. I do take
care to use drive cleanup utilities and use Smart Defrag and run Advanced
System Care and I don't have any reported problems, but I don't know exactly
why Windows backup folders for jOrgan would be visible in the Open>File>path
of just one application.

John

-----Original Message-----
From: Rick (greenfox)
Sent: Saturday, April 23, 2011 9:07 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] Version Associations and such

Hello again John.

I apologise if it seemed I was telling you what you already knew. I was
commenting on the symptom, not aware of the steps you had taken to get
there.
Rick (greenfox)
2011-04-24 13:02:13 UTC
Permalink
There is a important difference between a "shortcut icon" and an
"associated file".

With a "shortcut icon" you can specify details of the target file and
how you intend it to be run.

With an "associated file" Windows simply sees the extension after the
dot. If there is a program "associated" by Windows to this suffix,
Windows will attempt to open the file with the program associated in the
registry. (if there is no "association" to the file suffix, Windows
does not recognise the file, it doesn't give it an icon, and doesn't
know what to do if you double click on the file. If you look at the
file properties it will say "opens with: unknown application")

Windows is only capable of associating one program with a particular
file suffix (the part of the file name after the dot).

As an example, you may have a number of programs on your computer that
will play .mp3 files. If you double click on a .mp3 file only one
program will open and play the file. If you open some other program
first, you can play the .mp3 program in that other program without any
problem.

jOrgan is most likely the only program on your computer where you have
more than one version of the same program. That is why it is the only
program where you experience this problem.

Regards
Rick
Post by John Beach
I know that a shortcut icon relates specifically to a program version by
properties>target>drive>path, so two or more .exe files of the same
application or program ARE distinguished at least by the linkage of
target>drive>path. I don't believe Windows suffers from dysfunction because
there are more than one .exe file of jOrgan and it can't determine which of
the two or more .exe files it is supposed to open. They are either
installed as identifiably separate entities or they are overwritten by the
newer installation.
Matt Pestle
2011-04-22 02:08:50 UTC
Permalink
Yes, I agree, a good case can be made for the ability to save:
- My personal input/output devices
- My personal "messages" (in particular combination piston messages)
separately, and to be able to retain them across disposition releases, or insert them into new dispositions, and indeed I have scripts which do just this for me. This basically embodies what I think this entire discussion is about. The exact same thing is easily accomplished through the GUI. I'm just GUI averse - the mouse is the most damaging and cumbersome invention ever produced, IMHO.

Limiting my web app idea to this could possibly result in something useful. But the only possible way to accomplish any of this is through the hidden unique identifier of each element, internal to the disposition. So disposition developers would also have to be bound by a "contract" in order to use it - for instance, thou shalt not delete a keyboard and recreate it (thus losing the information that all users had stored about the keyboard). Forcing this contract on disposition developers seems to me to be a step backwards. Given the fact that nobody ever sees this unique identifier without looking at the resulting XML, it will be very difficult to even *define* this contract.

I don't think the reason the developer is silent on the issue is just because he's enjoying an Easter holiday.


I think more useful were other ideas I had for my little web application which would help disposition developers examine things that I think the current GUI lacks (or more likely that I haven't discovered yet). For example, how to address questions like these:

- I have 10 combination elements for the Swell stops. How can I quickly ensure that all 10 reference exactly the same stops and I didn't accidentally leave one out in number 4?
- My "transpose" elements are supposed to reference all stops. How can I quickly ensure that they actually do?
- Does my "memory" element reference all of the things that it needs to? Did I leave something out?
- Did I remember to put a reasonable name/description on all of my elements, so that when I go looking for them in construct mode I don't see 4 elements called "2" and wonder which one belongs to the Swell division?

I find the construction of dispositions to be prone to human error, but involving things which a machine can do easily.

I have a series of transformations that input a disposition and kick me out a series of reports, and I can immediately identify shortcomings in many dispositions that are released. The transformations are, however, based on my own understanding of the format of the disposition file, which is still somewhat limited.

But this is probably a new thread to pick up on someday.

Cheers,
Matt
Post by BCA
Hi Matt,
I agree. A global default setup seems like trying to keep all the
mouseclicks jOrgan just is designed for, a "contradiction in terms".
WHICH parametres should be integrated into such a configuration file.
AFAICS those are only the channels for the keyboards, and perhaps the
settings for combination buttons.
...
BCA
2011-04-22 10:45:47 UTC
Permalink
Hi Matt,

I find those little developments by you very interesting, this could be very
helpful for the disposition development. Keeping this in mind, I shall
research which such questions rise in me during the process. There are many
little things... Do you remember Lynn has made something in a similar way,
some time ago?

Many thanks and Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3467759.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Matt Pestle
2011-04-22 20:41:42 UTC
Permalink
I don't - sorry. It could have been before I began following jOrgan. Can you give me a hint to search for or an approximate date?
Post by BCA
Do you remember Lynn has made something in a similar way,
some time ago?
BCA
2011-04-23 05:48:58 UTC
Permalink
Hi Matt,
this we must ask Lynn himself.

Lynn, in case you're reading with us - do you still provide your web
applications you made some time ago? Can you provide a link?

Many thanks and regards
Bernd.



--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3469428.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Lynn Walls
2011-04-23 13:57:11 UTC
Permalink
Sadly, they are not available presently.

To refresh everyone's memory and for newcomers, those utilities read the jOrgan
.disposition file and produced a printed output in tabular format of the various elements
and their properties. The printed reports helped those who work with dispositions to
visualize the element relationships, and see at a glance, what elements were referenced by
what other elements. They help find reference omissions and "stray" references that could
cause developer headaches with things that were not working correctly.

Users would run these utilities on a web server that I provided by uploading their
.disposition files to my server and selecting the report options on the upload link page.

Since these utility programs were very sensitive to the structure and content of the
.disposition XML file they had to be reviewed and often updated to handle any changes made
with each new version of jOrgan. Worse: they also had to retain the old logic that
allowed them to continue to make reports for older versions of jOrgan.

When Sven divided the .disposition structure into two separate files, with the combination
memories separated out to a separate file, I stopped trying to keep the utilities up to
date. However, for a time they continued to work satisfactorily for the .disposition file
-- but memory reporting was lost. The biggest issue was how to upload TWO files
simultaneously to the server without having the user have to put them into a SINGLE zip file.

Then, a couple of months ago the hard drive of the computer that I was using as a web
server for this project died. This was the final nail in the coffin for the utilities. I
never did get that server running again.

CLW
----------------------------------------------------------------------------
Post by BCA
Hi Matt,
this we must ask Lynn himself.
Lynn, in case you're reading with us - do you still provide your web
applications you made some time ago? Can you provide a link?
Many thanks and regards
Bernd.
--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3469428.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Jonathan Aquilina
2011-04-23 14:55:13 UTC
Permalink
Lynn i might be able to help resurrect this if this is really a useful
tool i have a server given to me by work. im more then willing to revive
this :) as well lynn maintain and update said program.
Post by Lynn Walls
The printed reports helped those who work with dispositions to
visualize the element relationships, and see at a glance, what elements were referenced by
what other elements. They help find reference omissions and "stray" references that could
cause developer headaches with things that were not working correctly.
Users would run these utilities on a web server that I provided by uploading their
.disposition files to my server and selecting the report options on the upload link page.
Since these utility programs were very sensitive to the structure and content of the
.disposition XML file they had to be reviewed and often updated to handle any changes made
with each new version of jOrgan. Worse: they also had to retain the old logic that
allowed them to continue to make reports for older versions of jOrgan.
When Sven divided the .disposition structure into two separate files, with the combination
memories separated out to a separate file, I stopped trying to keep the utilities up to
date. However, for a time they continued to work satisfactorily for the .disposition file
-- but memory reporting was lost. The biggest issue was how to upload TWO files
simultaneously to the server without having the user have to put them into a SINGLE zip file.
Then, a couple of months ago the hard drive of the computer that I was using as a web
server for this project died. This was the final nail in the coffin for the utilities. I
never did get that server running again.
Lynn Walls
2011-04-23 15:17:39 UTC
Permalink
The utilities were written in Perl 5.6, and run as cgi-bin scripts by the Apache web server.

CLW
----------------------------------------------------------------------
Post by Jonathan Aquilina
Lynn i might be able to help resurrect this if this is really a useful
tool i have a server given to me by work. im more then willing to revive
this :) as well lynn maintain and update said program.
Jonathan Aquilina
2011-04-23 16:39:59 UTC
Permalink
lynn what do you think about porting it to a java app that can be
bundled with the installer and run from a local machine if it is
installed by a particular user.
Post by Lynn Walls
The utilities were written in Perl 5.6, and run as cgi-bin scripts by the Apache web server.
CLW
----------------------------------------------------------------------
Post by Jonathan Aquilina
Lynn i might be able to help resurrect this if this is really a useful
tool i have a server given to me by work. im more then willing to revive
this :) as well lynn maintain and update said program.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Lynn Walls
2011-04-23 18:39:28 UTC
Permalink
It would probably be a lot of work for little benefit. Everything that these utilities
reported can actually be discovered by navigating through all the jOrgan elements in
Construct mode. The utility reports simply made it easier to see everything as a
continuous tabular report rather than having to mouse around through the jOrgan element
and reference structure in Construct mode.

Not only would it be a lot of work to convert these Perl programs to another
language/platform, but thereafter someone would have to keep aware of all .disposition
structure changes and modify the utility programs to track accordingly -- while at the
same time maintaining backward compatibility with .disposition files created in previous
jOrgan versions. (Surely you would not want to have to deal with separate versions of all
the utility programs that were individually tied to specific versions of jOrgan. If the
day ever comes when jOrgan becomes totally settled and no more updates are forthcoming, it
might be "interesting" (but still not "worthwhile") to update the utilities.

Bottom line: For something that does not have a positive revenue stream, all this effort
is not worth the trouble.

CLW
-------------------------------------------------------------
Post by Jonathan Aquilina
lynn what do you think about porting it to a java app that can be
bundled with the installer and run from a local machine if it is
installed by a particular user.
Post by Lynn Walls
The utilities were written in Perl 5.6, and run as cgi-bin scripts by the Apache web server.
CLW
----------------------------------------------------------------------
Post by Jonathan Aquilina
Lynn i might be able to help resurrect this if this is really a useful
tool i have a server given to me by work. im more then willing to revive
this :) as well lynn maintain and update said program.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-23 19:13:15 UTC
Permalink
True, Lynn, but current always has a positive revenue stream, it is just
that current is fighting an uphill battle against the stream. Turn on a
light and ask if it is worth the trouble!
National Grid is not complaining!

John

-----Original Message-----
From: Lynn Walls
Sent: Saturday, April 23, 2011 2:39 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] .disposition reporting utilities

It would probably be a lot of work for little benefit. Everything that
these utilities
reported can actually be discovered by navigating through all the jOrgan
elements in
Construct mode. The utility reports simply made it easier to see everything
as a
continuous tabular report rather than having to mouse around through the
jOrgan element
and reference structure in Construct mode.

Not only would it be a lot of work to convert these Perl programs to another
language/platform, but thereafter someone would have to keep aware of all
.disposition
structure changes and modify the utility programs to track accordingly --
while at the
same time maintaining backward compatibility with .disposition files created
in previous
jOrgan versions. (Surely you would not want to have to deal with separate
versions of all
the utility programs that were individually tied to specific versions of
jOrgan. If the
day ever comes when jOrgan becomes totally settled and no more updates are
forthcoming, it
might be "interesting" (but still not "worthwhile") to update the utilities.

Bottom line: For something that does not have a positive revenue stream, all
this effort
is not worth the trouble.

CLW
-------------------------------------------------------------
Post by Jonathan Aquilina
lynn what do you think about porting it to a java app that can be
bundled with the installer and run from a local machine if it is
installed by a particular user.
Post by Lynn Walls
The utilities were written in Perl 5.6, and run as cgi-bin scripts by the
Apache web server.
CLW
----------------------------------------------------------------------
Post by Jonathan Aquilina
Lynn i might be able to help resurrect this if this is really a useful
tool i have a server given to me by work. im more then willing to revive
this :) as well lynn maintain and update said program.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Rick (greenfox)
2011-04-23 10:48:27 UTC
Permalink
Hello Matt

Your analyser sounds very interesting.

Regards
Rick
Post by Matt Pestle
- My personal input/output devices
- My personal "messages" (in particular combination piston messages)
separately, and to be able to retain them across disposition releases, or insert them into new dispositions, and indeed I have scripts which do just this for me. This basically embodies what I think this entire discussion is about. The exact same thing is easily accomplished through the GUI. I'm just GUI averse - the mouse is the most damaging and cumbersome invention ever produced, IMHO.
Limiting my web app idea to this could possibly result in something useful. But the only possible way to accomplish any of this is through the hidden unique identifier of each element, internal to the disposition. So disposition developers would also have to be bound by a "contract" in order to use it - for instance, thou shalt not delete a keyboard and recreate it (thus losing the information that all users had stored about the keyboard). Forcing this contract on disposition developers seems to me to be a step backwards. Given the fact that nobody ever sees this unique identifier without looking at the resulting XML, it will be very difficult to even *define* this contract.
I don't think the reason the developer is silent on the issue is just because he's enjoying an Easter holiday.
- I have 10 combination elements for the Swell stops. How can I quickly ensure that all 10 reference exactly the same stops and I didn't accidentally leave one out in number 4?
- My "transpose" elements are supposed to reference all stops. How can I quickly ensure that they actually do?
- Does my "memory" element reference all of the things that it needs to? Did I leave something out?
- Did I remember to put a reasonable name/description on all of my elements, so that when I go looking for them in construct mode I don't see 4 elements called "2" and wonder which one belongs to the Swell division?
I find the construction of dispositions to be prone to human error, but involving things which a machine can do easily.
I have a series of transformations that input a disposition and kick me out a series of reports, and I can immediately identify shortcomings in many dispositions that are released. The transformations are, however, based on my own understanding of the format of the disposition file, which is still somewhat limited.
But this is probably a new thread to pick up on someday.
Cheers,
Matt
Post by BCA
Hi Matt,
I agree. A global default setup seems like trying to keep all the
mouseclicks jOrgan just is designed for, a "contradiction in terms".
WHICH parametres should be integrated into such a configuration file.
AFAICS those are only the channels for the keyboards, and perhaps the
settings for combination buttons.
...
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
DellAnderson
2011-04-21 15:03:54 UTC
Permalink
Bernd,

Even after viewing your schematic diagram, I'm still not sure I see how your
idea differs from Rick and mine (and others), except that it appears to
limit the user to only one hardware console.

Also do not see how it could dispositions with different goals (e.g. 2 man
german baroque vs 4 man theater organ or one manual harpsichord).

In any case, these are all speculative moot point ideas given that Sven
previously stated that he did not have time to work on this and I certainly
do not have the expertise to add to the open source code.

best,

Dell

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3466128.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Rick (greenfox)
2011-04-19 12:48:04 UTC
Permalink
I agree

Altering multiple dispositions for use on a new version can be tedious.
I know Sven does all he can to make each upgrade automatic but it is not
always the case.

When we get a new version of jOrgan or something new from a disposition
developer, there is quite some work in getting it ready to play.

My setup has 3 keyboards, pedal board, single swell, 32 combination
pistons and 4 toy-counter triggers. It is only my own christie
disposition that I maintain set up to utilise all of this, nothing else
ever stays the same long enough to warrant the work.

In jOrgan version 3.10 I set up 11x dispositions to give a talk on
virtual organs. I had about 40 people present on the afternoon.

Regards
Rick
Post by DellAnderson
Having struggled with multi-instance FluidSynth long enough to be tired of
them, I think the true answer will be when Sven is able to break apart the
sound triggering and generation from the dispositions.
I only have 3 different MIDI keyboards
There are (conservatively) 12 dispositions
Why should I have to configure jOrgan 12 times? If there was a separate
module for configuring to the keyboard (with the option to 'save settings'
under different names if necessary), it would truly simplify setup.
orgel jeux
2011-04-19 15:00:26 UTC
Permalink
I am also in favour of such a development, specially if it includes also the
swell pedals which happen to have quite peculiar settings in my console.

Way in future we could even have this universal stopswitch interface.....But
perhaps with the SAMS-complexity this is asking too much.

Main problem for adjusting everytime is the FS assignments; although we can
already adapt certain parameters in the customisation.

In the far future, we could perhaps do a single adjustment, not seeing
anymore that internally there are more instances.

In that situation you would have a general organ output setting, assigning a
stereo pair to your specific audio device and/or channels, and a assignment
part that is specifically dealing with assigning rank outputs to audio (
channel) ouputs.

But perhaps for the more ict-oriented people this all is not important;
perhaps with such a shell around the main jOrgan core, it gets too
commercial for a free development......

Bu as soon as all wishes concerning the integrated audio part are
fullfilled, people will be glad to spend some time with their
customisation...........

Greetings,

Geert
Post by Rick (greenfox)
I agree
Altering multiple dispositions for use on a new version can be tedious.
I know Sven does all he can to make each upgrade automatic but it is not
always the case.
When we get a new version of jOrgan or something new from a disposition
developer, there is quite some work in getting it ready to play.
My setup has 3 keyboards, pedal board, single swell, 32 combination
pistons and 4 toy-counter triggers. It is only my own christie
disposition that I maintain set up to utilise all of this, nothing else
ever stays the same long enough to warrant the work.
In jOrgan version 3.10 I set up 11x dispositions to give a talk on
virtual organs. I had about 40 people present on the afternoon.
Regards
Rick
Post by DellAnderson
Having struggled with multi-instance FluidSynth long enough to be tired
of
Post by DellAnderson
them, I think the true answer will be when Sven is able to break apart
the
Post by DellAnderson
sound triggering and generation from the dispositions.
I only have 3 different MIDI keyboards
There are (conservatively) 12 dispositions
Why should I have to configure jOrgan 12 times? If there was a separate
module for configuring to the keyboard (with the option to 'save
settings'
Post by DellAnderson
under different names if necessary), it would truly simplify setup.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
BCA
2011-04-19 17:49:36 UTC
Permalink
Gentlemen,

the development of a default hardware interface is impossible until we
haven't developed a default hardware console. But a default hardware console
is opposite to everything jOrgan embodies.

For instance, how shall I adapt Ricks 32 combination switches to my 10
combinations hardware combinations interface, without adapting all my
keyboard shortcuts manually, and deciding which of the 32 combinations I
shall abandon?

Regards
Bernd.





--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3461075.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
orgel jeux
2011-04-19 18:39:28 UTC
Permalink
Like they do it in .........^&*(())

Geert
Post by BCA
Gentlemen,
the development of a default hardware interface is impossible until we
haven't developed a default hardware console. But a default hardware console
is opposite to everything jOrgan embodies.
For instance, how shall I adapt Ricks 32 combination switches to my 10
combinations hardware combinations interface, without adapting all my
keyboard shortcuts manually, and deciding which of the 32 combinations I
shall abandon?
Regards
Bernd.
--
http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3461075.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
BCA
2011-04-20 08:57:10 UTC
Permalink
Geert,

I don't know "how they do it in Hauptwerk". But I know many soldering
companies doing hardware consoles built for Hauptwerk dispositions. Absurde
business, seen from a universal point of view. Money, money, money.

It is not possible to adapt Rick's 32 combinations to a 10 combinations
hardware device, except I change my hardware device. All other things are
tricky but workarounds.

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3462482.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
orgel jeux
2011-04-20 10:11:15 UTC
Permalink
Bernd, you aree right, of course.

I did not read your comment properly, squeezing 32 comb into 10 buttons is
impossible.

What you see sometimes, for instance in my Roland G1000 synth, is, that it
is organised as several banks and in every bank 8 selections.

In that case you can do with less physical switches. But I think, that is
not a good idea for changing registrations on the fly.

The most successful manufacturor in the Netherlands for HW consoles is
Mixtuur. They have built all presets into the console memory; it sends out
all stopswitching commands on the fly when a preset is activated.
In that way they shortcut the specific disposition-presets, which vary in
amount between none and too many in the different models.

For the rest, most of them fully rely on the touch-screen, which I myself
dislike a bit.


But the most powerful "preset" is the combination sequencer, that can be
activated at will by hand- or footpiston.
This only needs 1 ( 2) button(s).
Only you have to program it, and it gives much less freedom when
improvising. I never use it.

Greetings,

Geert
Post by BCA
Geert,
I don't know "how they do it in Hauptwerk". But I know many soldering
companies doing hardware consoles built for Hauptwerk dispositions. Absurde
business, seen from a universal point of view. Money, money, money.
It is not possible to adapt Rick's 32 combinations to a 10 combinations
hardware device, except I change my hardware device. All other things are
tricky but workarounds.
Regards
Bernd.
--
http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3462482.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Rick (greenfox)
2011-04-20 14:51:29 UTC
Permalink
I try to consider there will be users with different facilities. In my
piston numbering I start with the General pistons in order from 1, so
someone with 10 will have the first 10 General pistons.

Once the MIDI messages are in the jOrgan disposition, it is very easy
with Sven's "Customizer" window to "Teach" the disposition which switch
should trigger which piston.

For a one solution fits all front end to jOrgan, I think it would simply
need jOrgan (with no disposition loaded) to store the external MIDI data
for a number of console arrangements (maybe unlimited with a user
designated file name for each) these would just be X number of
keyboards, X number of analogue (swell, crescendo), X number of pistons
etc. Each disposition would then link to the available hardware items
(not directly out to actual MIDI addresses).

The owner of the console hardware could name each item with a text name.
The disposition builder would name each item with a text name.
You would just need to marry the two up. It would be a once only job
that was then saved as a file.

Regards
Rick
Post by BCA
Gentlemen,
the development of a default hardware interface is impossible until we
haven't developed a default hardware console. But a default hardware console
is opposite to everything jOrgan embodies.
For instance, how shall I adapt Ricks 32 combination switches to my 10
combinations hardware combinations interface, without adapting all my
keyboard shortcuts manually, and deciding which of the 32 combinations I
shall abandon?
Regards
Bernd.
--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3461075.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
BCA
2011-04-20 17:33:31 UTC
Permalink
Hello Rick,
I'm not quite sure if I understand right.

You mean, jOrgan shall provide a bunch of different user-alterable standard
setups for - in our case - organ instruments, while the disposition
constructor mentions which jOrgan standard setup shall be used for the
particular instrument?

For xample: jOrgan provides a 2M+P standard theatre organ setup "X", the
user has altered once, to fit his hardware setting. The disposition
constructor mentions that for his 2M+P theatre organ the standard setup "X"
shall be used, and he uses this abstract scheme already during construction
of his disposition.

Do I understand your approach alright?

Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463665.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Panos Ghekas
2011-04-20 18:46:58 UTC
Permalink
Rick, Bernd,
Interesting, but I prefere as we are on this.It's ok to customize any disposition to my hardware console, so I know every second what's happening and what I want to alter, delete or add on this disposition after I play with it.
As you may know from my publicly shared dispositions, I leave customize boxes empty, for this exact reason. So any user can adapt it to its needs.ie the Russell I got here has settings on these boxes that correspond to my EL900 functions perfectly. I do not expect any other user (unless he/she got an EL900 or EL90 series) to use these. The Russell I upoloaded is different, has empty boxes (unless I forgot to delete ! ooops).
The same with general pistons and/or divisionals. For example I do not have any divisionals. So any disposition with them renders these useless here. I walk with my 16 generals. Or if on this given dispo there are 8divisionals and 8 generals I'm ok. I adapt accordingly. It's not big deal for us users to get use to work with customize as is.There are people who still learning how to use jOrgan 3.12, 3.11.1, 3.10, or even 3.8.2, why we need so many improvements in a so short time ?
Our aim is Music and get better quality sound, AND GET TIME TO PLAY WITH ALL THESE AMAZING GEMS, of course through a best jOrgan, but too many steps in a very short time is messy IMHO. It makes new people to jOrgan to stop using or stay with the older version they use to.
You and me and all public disposition developers we're OK as we need to know every new feature Sven and with all dicussion/proposals here, introduce, but I'm afraid that many users cannot copy that fast.....
Dunno, just put fuel for discussion
All the bestPanos

--- Óôéò Ôåô., 20/04/11, ï/ç Rick (greenfox) <***@gmail.com> Ýãñáøå
I try to consider there will be users with different facilities.  In my
piston numbering I start with the General pistons in order from 1, so
someone with 10 will have the first 10 General pistons.

Once the MIDI messages are in the jOrgan disposition, it is very easy
with Sven's "Customizer" window to "Teach" the disposition which switch
should trigger which piston.

For a one solution fits all front end to jOrgan, I think it would simply
need jOrgan (with no disposition loaded) to store the external MIDI data
for a number of console arrangements (maybe unlimited with  a user
designated file name for each) these would just be X number of
keyboards, X number of analogue (swell, crescendo), X number of pistons
etc.  Each disposition would then link to the available hardware items
(not directly out to actual MIDI addresses).

The owner of the console hardware could name each item with a text name.
The disposition builder would name each item with a text name.
You would just need to marry the two up.  It would be a once only job
that was then saved as a file.

Regards
Rick
Panos Ghekas
2011-04-20 19:04:38 UTC
Permalink
Hey Dell, NICE !!! very very clear now.
This is more or less like the way  MysticOrgan program helps creating sets for GrandOrgue... hmmm
Is it possible Sven?
bestPanos
--- Óôéò Ôåô., 20/04/11, ï/ç DellAnderson <***@anim8.com> Ýãñáøå:

Áðü: DellAnderson <***@anim8.com>
ÈÝìá: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Ðñïò: jorgan-***@lists.sourceforge.net
Çìåñïìçíßá: ÔåôÜñôç, 20 Áðñßëéïò 2011, 18:38

Here's a graphic of what I have imagined.  Feel free to improve:
http://jorgan.999862.n4.nabble.com/file/n3463827/ProposedJOrganModularity.png

best,

Dell


--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3463827.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Panos Ghekas
2011-04-21 18:27:18 UTC
Permalink
I agree with Lynn.

Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept just download and install.

jOrgan is not for pipe organs only. Remember my piano/strings dispo. There's a hold stop like the ones found on synths.
I use jorgan to control big samplers with any type of instrument loaded in 16 channels at least.

Matt was right that there are users with 4:3 screens and is hard for them when a dispo creator releases for 16:9. Two screen versions by the creator is the solution, not in software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect depending on the organ, or even the synthesizer (!) yes. I got one dispo with two keybords for conrollers, one for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the other for a 61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.

Configuration wizard is very good as it is IMHO, it's up to the disposition creator to work harder to cover as many users' needs as he can (I'm not sayin' she as we don't have any lady dispo creator... yet).

As time goes by and we know each other better, more or less we know how our physical consoles are, add to that this jOrgan-life-pictures topics (gooood!), so dispositions can be this way for work for the most of us.
A data base of "Registered Users Physical consoles and/or kbd controllers" would be very useful I'm thinkin', so I would know for whom I'm gonna make things.
Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?
Since I know he will love it and use it in Church !!
Or someone with a 3man console that he/she needs some stops for the 3rd man and he/she's got a two man dispo.

Private e-mails are good for this. Why not ask ? Is it possible to? Then it's up to the creator if he will, as time and obligations permits. Seems like an after sales concept, I know, but here we're a kinda familly, or community.

Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea, many others would beneffit from, but, I didn't know how to do it, he did, I uploaded this alternate version and so on.

My point is we can work together in some level and cannot expect everything from Sven.

Ah, some good news. Hauptwerk 4 is released and guess what : it has a midi recorder in it..... he he, jOrgan has it for sooooo long, also F11 full screen (now?) and Midi out for all versions :-) and some customizing features......
Beyond jokes, HW4 is powerfull but all the above proves that jOrgan leads the way in some extremelly useful features.

Best
Panos

--- Óôéò ÐÝì., 21/04/11, ï/ç Lynn Walls <***@gmail.com> Ýãñáøå:
Yes...my two-layer (disposition file/config file) solution is essentially intended to help
the disposition developer --- NOT the end user.  There would have to be a .config file
tailored to each unique disposition.  That is necessary because each disposition would
potentially have a different number of keyboards, a different number of swells, and a
different number of stops, couplers, trems and any other switches.  It would not be
feasible to define all these objects with any sort of "standard" nomenclature.  Just for
example, the manuals in classical/church organ terminology are named completely
differently than those of a theatre organ.  And even within each of those classes of organ
the nomenclature often varies.  And what about harpsichords, and electronic synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan can potentially
support?  Don't assume that jOrgan is only only for pipe organs.  So don't try to come up
with some "standard" that only addresses pipe organs.  Simply put: just leave it up to the
disposition developer to name those input and output devices in the most meaningful way so
that when the Configuration WIZARD presents those names to the end user, that end user
will know what physical device needs to be connected to that name.

It is the robustness of the WIZARD that will help the "lazy" end user -- NOT the layered
disposition/config file architecture.

You'll never get anywhere with trying to make it simpler for the end user that a good
configuration WIZARD.  Face it: at a MINIMUM, the end user will HAVE to understand his
MIDI hardware, and he will HAVE to go through a configuration process at least ONCE per
different organ definition disposition.  Even Hauptwerk does not make it simpler than
this!  In fact, Hauptwerk's configuration wizard could probably be used as a functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the scope,
channel and device of every keyboard and continuous controller (swell).

Any user who wants to be "lazier" than this probably does not deserve much consideration
from this forum.  If Sven were trying to make money from selling jOrgan licenses, he might
be inclined to bend-over-backwards for the ultra-lazy dummy.  But given the monetary
compensation involved, I would be surprised if any serious help would be forthcoming for
any end user who is unwilling to work through a configuration wizard at least once for
each distinct disposition that he wants to use.

CLW
------------------------------------------------------------------------
Roy Radford
2011-04-21 18:42:04 UTC
Permalink
   "I'm not sayin' she as we don't have any lady dispo creator... yet)."

   ...Come to think of it, do we have any ladies here at all?


         Have fun,

            Roy.


--- On Thu, 21/4/11, Panos Ghekas <***@yahoo.gr> wrote:

From: Panos Ghekas <***@yahoo.gr>
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Thursday, 21 April, 2011, 19:27

I agree with Lynn.

Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept just download and install.

jOrgan is not for pipe organs only. Remember my piano/strings dispo. There's a hold stop like the ones found on synths.
I use jorgan to control big samplers with any type of instrument loaded in 16 channels at least.

Matt was right that there are users with 4:3 screens and is hard for them when a dispo creator releases for 16:9. Two screen versions by the creator is the solution, not in software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect depending on the organ, or even the synthesizer (!) yes. I got one dispo with two keybords for conrollers, one for an 88 piano type , engaging
piano,rhodes,CP80,Clavinet ect and the other for a 61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.

Configuration wizard is very good as it is IMHO, it's up to the disposition creator to work harder to cover as many users' needs as he can (I'm not sayin' she as we don't have any lady dispo creator... yet).

As time goes by and we know each other better, more or less we know how our physical consoles are, add to that this jOrgan-life-pictures topics (gooood!), so dispositions can be this way for work for the most of us.
A data base of "Registered Users Physical consoles and/or kbd controllers" would be very useful I'm thinkin', so I would know for whom I'm gonna make things.
Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?
Since I know he will love it and use it in Church !!
Or someone with a 3man console that he/she needs some stops for the 3rd man and he/she's got a two man
dispo.

Private e-mails are good for this. Why not ask ? Is it possible to? Then it's up to the creator if he will, as time and obligations permits. Seems like an after sales concept, I know, but here we're a kinda familly, or community.

Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea, many others would beneffit from, but, I didn't know how to do it, he did, I uploaded this alternate version and so on.

My point is we can work together in some level and cannot expect everything from Sven.

Ah, some good news. Hauptwerk 4 is released and guess what : it has a midi recorder in it..... he he, jOrgan has it for sooooo long, also F11 full screen (now?) and Midi out for all versions :-) and some customizing features......
Beyond jokes, HW4 is powerfull but all the above proves that jOrgan leads the way in some extremelly useful features.

Best
Panos

--- Στις ΠέΌ., 21/04/11, ο/η
Lynn Walls <***@gmail.com> έγραψε:
Yes...my two-layer (disposition file/config file) solution is essentially intended to help
the disposition developer --- NOT the end user.  There would have to be a .config file
tailored to each unique disposition.  That is necessary because each disposition would
potentially have a different number of keyboards, a different number of swells, and a
different number of stops, couplers, trems and any other switches.  It would not be
feasible to define all these objects with any sort of "standard" nomenclature.  Just for
example, the manuals in classical/church organ terminology are named completely
differently than those of a theatre organ.  And even within each of those classes of organ
the nomenclature often
varies.  And what about harpsichords, and electronic synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan can potentially
support?  Don't assume that jOrgan is only only for pipe organs.  So don't try to come up
with some "standard" that only addresses pipe organs.  Simply put: just leave it up to the
disposition developer to name those input and output devices in the most meaningful way so
that when the Configuration WIZARD presents those names to the end user, that end user
will know what physical device needs to be connected to that name.

It is the robustness of the WIZARD that will help the "lazy" end user -- NOT the layered
disposition/config file architecture.

You'll never get anywhere with trying to make it simpler for the end user that a good
configuration WIZARD.  Face it: at a MINIMUM, the end user will HAVE to understand his
MIDI
hardware, and he will HAVE to go through a configuration process at least ONCE per
different organ definition disposition.  Even Hauptwerk does not make it simpler than
this!  In fact, Hauptwerk's configuration wizard could probably be used as a functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the scope,
channel and device of every keyboard and continuous controller (swell).

Any user who wants to be "lazier" than this probably does not deserve much consideration
from this forum.  If Sven were trying to make money from selling jOrgan licenses, he might
be inclined to bend-over-backwards for the ultra-lazy dummy.  But given the monetary
compensation involved, I would be surprised if any serious help would be forthcoming for
any end user who is unwilling to work through a configuration wizard at least once for
each distinct disposition that he wants to
use.

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


-----Inline Attachment Follows-----
Lynn Walls
2011-04-21 18:53:38 UTC
Permalink
Roy,

I attended grammar school in the 1960s. There we learned that the personal pronouns "he"
and "him" and suffix "-man" stood for BOTH male and female whenever a general
(non-specific) person was being referenced. This definition has always been good enough
for me, and I have never bought into the extremely awkward "he/she", "him/her", "-person"
terminology. Those constructs do not add any meaning to the dialog, and only serve to
appease the "politically correct" crowd.

CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module
abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Date: Thursday, 21 April, 2011, 19:27
I agree with Lynn.
Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept
just download and install.
jOrgan is not for pipe organs only. Remember my piano/strings dispo. There's a hold
stop like the ones found on synths.
I use jorgan to control big samplers with any type of instrument loaded in 16 channels
at least.
Matt was right that there are users with 4:3 screens and is hard for them when a dispo
creator releases for 16:9. Two screen versions by the creator is the solution, not in
software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect depending on the organ,
or even the synthesizer (!) yes. I got one dispo with two keybords for conrollers, one
for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the other for a
61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
Configuration wizard is very good as it is IMHO, it's up to the disposition creator to
work harder to cover as many users' needs as he can (I'm not sayin' she as we don't
have any lady dispo creator... yet).
As time goes by and we know each other better, more or less we know how our physical
consoles are, add to that this jOrgan-life-pictures topics (gooood!), so dispositions
can be this way for work for the most of us.
A data base of "Registered Users Physical consoles and/or kbd controllers" would be
very useful I'm thinkin', so I would know for whom I'm gonna make things.
Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?
Since I know he will love it and use it in Church !!
Or someone with a 3man console that he/she needs some stops for the 3rd man and
he/she's got a two man dispo.
Private e-mails are good for this. Why not ask ? Is it possible to? Then it's up to
the creator if he will, as time and obligations permits. Seems like an after sales
concept, I know, but here we're a kinda familly, or community.
Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea, many others would
beneffit from, but, I didn't know how to do it, he did, I uploaded this alternate
version and so on.
My point is we can work together in some level and cannot expect everything from Sven.
Ah, some good news. Hauptwerk 4 is released and guess what : it has a midi recorder in
it..... he he, jOrgan has it for sooooo long, also F11 full screen (now?) and Midi out
for all versions :-) and some customizing features......
Beyond jokes, HW4 is powerfull but all the above proves that jOrgan leads the way in
some extremelly useful features.
Best
Panos
Yes...my two-layer (disposition file/config file) solution is essentially intended
to help
the disposition developer --- NOT the end user. There would have to be a .config file
tailored to each unique disposition. That is necessary because each disposition would
potentially have a different number of keyboards, a different number of swells, and a
different number of stops, couplers, trems and any other switches. It would not be
feasible to define all these objects with any sort of "standard" nomenclature.
Just for
example, the manuals in classical/church organ terminology are named completely
differently than those of a theatre organ. And even within each of those classes
of organ
the nomenclature often varies. And what about harpsichords, and electronic synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan can
potentially
support? Don't assume that jOrgan is only only for pipe organs. So don't try to
come up
with some "standard" that only addresses pipe organs. Simply put: just leave it up
to the
disposition developer to name those input and output devices in the most
meaningful way so
that when the Configuration WIZARD presents those names to the end user, that end
user
will know what physical device needs to be connected to that name.
It is the robustness of the WIZARD that will help the "lazy" end user -- NOT the
layered
disposition/config file architecture.
You'll never get anywhere with trying to make it simpler for the end user that a good
configuration WIZARD. Face it: at a MINIMUM, the end user will HAVE to understand his
MIDI hardware, and he will HAVE to go through a configuration process at least
ONCE per
different organ definition disposition. Even Hauptwerk does not make it simpler than
this! In fact, Hauptwerk's configuration wizard could probably be used as a
functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the
scope,
channel and device of every keyboard and continuous controller (swell).
Any user who wants to be "lazier" than this probably does not deserve much
consideration
from this forum. If Sven were trying to make money from selling jOrgan licenses,
he might
be inclined to bend-over-backwards for the ultra-lazy dummy. But given the monetary
compensation involved, I would be surprised if any serious help would be
forthcoming for
any end user who is unwilling to work through a configuration wizard at least once
for
each distinct disposition that he wants to use.
CLW
------------------------------------------------------------------------
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
-----Inline Attachment Follows-----
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-21 20:03:35 UTC
Permalink
Absolutely right! For example, "If God had wanted man to fly He would have
given him wings." "Man," in this case, refers to humankind, male or
female. "Him" is the objective pronoun that, in this case, is applicable to
women as part of humankind as well. The "politically correct" crowd have
done little but confuse understanding by a distinct lack of precision in
communication based on traditional definition. As a trained linguist, I
find this particularly distasteful. It is difficult enough to deal with the
idiomatic expressions which are unique to languages and need to be
translated, to say nothing of the contemporary nuances of meaning that have
been co-opted by the liberals in re-definitions and which leave us all in a
state of utter confusion. Implication and inference are difficult and
varied enough without adding a third dimension of ethereal supposition.
So much for the "egg" and "Mother God."
John B.




-----Original Message-----
From: Lynn Walls
Sent: Thursday, April 21, 2011 2:53 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab

Roy,

I attended grammar school in the 1960s. There we learned that the personal
pronouns "he"
and "him" and suffix "-man" stood for BOTH male and female whenever a
general
(non-specific) person was being referenced. This definition has always been
good enough
for me, and I have never bought into the extremely awkward "he/she",
"him/her", "-person"
terminology. Those constructs do not add any meaning to the dialog, and
only serve to
appease the "politically correct" crowd.

CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module
abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Date: Thursday, 21 April, 2011, 19:27
I agree with Lynn.
Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept
just download and install.
jOrgan is not for pipe organs only. Remember my piano/strings dispo. There's a hold
stop like the ones found on synths.
I use jorgan to control big samplers with any type of instrument loaded in 16 channels
at least.
Matt was right that there are users with 4:3 screens and is hard for them when a dispo
creator releases for 16:9. Two screen versions by the creator is the solution, not in
software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect depending on the organ,
or even the synthesizer (!) yes. I got one dispo with two keybords for conrollers, one
for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the other for a
61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
Configuration wizard is very good as it is IMHO, it's up to the disposition creator to
work harder to cover as many users' needs as he can (I'm not sayin' she as we don't
have any lady dispo creator... yet).
As time goes by and we know each other better, more or less we know how our physical
consoles are, add to that this jOrgan-life-pictures topics (gooood!), so dispositions
can be this way for work for the most of us.
A data base of "Registered Users Physical consoles and/or kbd controllers" would be
very useful I'm thinkin', so I would know for whom I'm gonna make things.
Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?
Since I know he will love it and use it in Church !!
Or someone with a 3man console that he/she needs some stops for the 3rd man and
he/she's got a two man dispo.
Private e-mails are good for this. Why not ask ? Is it possible to? Then it's up to
the creator if he will, as time and obligations permits. Seems like an after sales
concept, I know, but here we're a kinda familly, or community.
Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea, many others would
beneffit from, but, I didn't know how to do it, he did, I uploaded this alternate
version and so on.
My point is we can work together in some level and cannot expect everything from Sven.
Ah, some good news. Hauptwerk 4 is released and guess what : it has a midi recorder in
it..... he he, jOrgan has it for sooooo long, also F11 full screen (now?) and Midi out
for all versions :-) and some customizing features......
Beyond jokes, HW4 is powerfull but all the above proves that jOrgan leads the way in
some extremelly useful features.
Best
Panos
Yes...my two-layer (disposition file/config file) solution is essentially intended
to help
the disposition developer --- NOT the end user. There would have
to be a .config file
tailored to each unique disposition. That is necessary because
each disposition would
potentially have a different number of keyboards, a different
number of swells, and a
different number of stops, couplers, trems and any other switches. It would not be
feasible to define all these objects with any sort of "standard" nomenclature.
Just for
example, the manuals in classical/church organ terminology are named completely
differently than those of a theatre organ. And even within each of those classes
of organ
the nomenclature often varies. And what about harpsichords, and
electronic synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan can
potentially
support? Don't assume that jOrgan is only only for pipe organs. So don't try to
come up
with some "standard" that only addresses pipe organs. Simply put: just leave it up
to the
disposition developer to name those input and output devices in the most
meaningful way so
that when the Configuration WIZARD presents those names to the end user, that end
user
will know what physical device needs to be connected to that name.
It is the robustness of the WIZARD that will help the "lazy" end user -- NOT the
layered
disposition/config file architecture.
You'll never get anywhere with trying to make it simpler for the
end user that a good
configuration WIZARD. Face it: at a MINIMUM, the end user will
HAVE to understand his
MIDI hardware, and he will HAVE to go through a configuration process at least
ONCE per
different organ definition disposition. Even Hauptwerk does not
make it simpler than
this! In fact, Hauptwerk's configuration wizard could probably be used as a
functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the
scope,
channel and device of every keyboard and continuous controller (swell).
Any user who wants to be "lazier" than this probably does not deserve much
consideration
from this forum. If Sven were trying to make money from selling jOrgan licenses,
he might
be inclined to bend-over-backwards for the ultra-lazy dummy. But given the monetary
compensation involved, I would be surprised if any serious help would be
forthcoming for
any end user who is unwilling to work through a configuration wizard at least once
for
each distinct disposition that he wants to use.
CLW
------------------------------------------------------------------------
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
-----Inline Attachment Follows-----
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
orgel jeux
2011-04-21 21:31:16 UTC
Permalink
John,

As you only answwered Lynn, I guess you do not agree with what I said?/

or did I not make myself clear enough?/

greetings,

Geert
Post by John Beach
Absolutely right! For example, "If God had wanted man to fly He would have
given him wings." "Man," in this case, refers to humankind, male or
female. "Him" is the objective pronoun that, in this case, is applicable to
women as part of humankind as well. The "politically correct" crowd have
done little but confuse understanding by a distinct lack of precision in
communication based on traditional definition. As a trained linguist, I
find this particularly distasteful. It is difficult enough to deal with the
idiomatic expressions which are unique to languages and need to be
translated, to say nothing of the contemporary nuances of meaning that have
been co-opted by the liberals in re-definitions and which leave us all in a
state of utter confusion. Implication and inference are difficult and
varied enough without adding a third dimension of ethereal supposition.
So much for the "egg" and "Mother God."
John B.
-----Original Message-----
From: Lynn Walls
Sent: Thursday, April 21, 2011 2:53 PM
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
Roy,
I attended grammar school in the 1960s. There we learned that the personal pronouns "he"
and "him" and suffix "-man" stood for BOTH male and female whenever a general
(non-specific) person was being referenced. This definition has always been
good enough
for me, and I have never bought into the extremely awkward "he/she", "him/her", "-person"
terminology. Those constructs do not add any meaning to the dialog, and only serve to
appease the "politically correct" crowd.
CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module
abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer
tab
Post by Roy Radford
Date: Thursday, 21 April, 2011, 19:27
I agree with Lynn.
Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept
just download and install.
jOrgan is not for pipe organs only. Remember my piano/strings dispo. There's a hold
stop like the ones found on synths.
I use jorgan to control big samplers with any type of instrument
loaded in 16 channels
at least.
Matt was right that there are users with 4:3 screens and is hard for
them when a dispo
creator releases for 16:9. Two screen versions by the creator is the
solution, not in
software. As 4xsound drivers versions (aka Direct, Asio, Jack,
WDMKS).
Post by Roy Radford
And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect
depending on the organ,
or even the synthesizer (!) yes. I got one dispo with two keybords
for
Post by Roy Radford
conrollers, one
for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and
the
Post by Roy Radford
other for a
61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
Configuration wizard is very good as it is IMHO, it's up to the
disposition creator to
work harder to cover as many users' needs as he can (I'm not sayin' she as we don't
have any lady dispo creator... yet).
As time goes by and we know each other better, more or less we know
how our physical
consoles are, add to that this jOrgan-life-pictures topics (gooood!),
so dispositions
can be this way for work for the most of us.
A data base of "Registered Users Physical consoles and/or kbd controllers" would be
very useful I'm thinkin', so I would know for whom I'm gonna make things.
Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?
Since I know he will love it and use it in Church !!
Or someone with a 3man console that he/she needs some stops for the 3rd man and
he/she's got a two man dispo.
Private e-mails are good for this. Why not ask ? Is it possible to? Then it's up to
the creator if he will, as time and obligations permits. Seems like
an
Post by Roy Radford
after sales
concept, I know, but here we're a kinda familly, or community.
Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea,
many others would
beneffit from, but, I didn't know how to do it, he did, I uploaded this alternate
version and so on.
My point is we can work together in some level and cannot expect
everything from Sven.
Ah, some good news. Hauptwerk 4 is released and guess what : it has a
midi recorder in
it..... he he, jOrgan has it for sooooo long, also F11 full screen
(now?) and Midi out
for all versions :-) and some customizing features......
Beyond jokes, HW4 is powerfull but all the above proves that jOrgan
leads the way in
some extremelly useful features.
Best
Panos
Yes...my two-layer (disposition file/config file) solution is
essentially intended
to help
the disposition developer --- NOT the end user. There would have
to be a .config file
tailored to each unique disposition. That is necessary because
each disposition would
potentially have a different number of keyboards, a different
number of swells, and a
different number of stops, couplers, trems and any other
switches.
Post by Roy Radford
It would not be
feasible to define all these objects with any sort of "standard" nomenclature.
Just for
example, the manuals in classical/church organ terminology are named completely
differently than those of a theatre organ. And even within each
of
Post by Roy Radford
those classes
of organ
the nomenclature often varies. And what about harpsichords, and
electronic synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan can
potentially
support? Don't assume that jOrgan is only only for pipe organs.
So
Post by Roy Radford
don't try to
come up
just leave it up
to the
disposition developer to name those input and output devices in the most
meaningful way so
that when the Configuration WIZARD presents those names to the
end
Post by Roy Radford
user, that end
user
will know what physical device needs to be connected to that
name.
Post by Roy Radford
It is the robustness of the WIZARD that will help the "lazy" end
user -- NOT the
layered
disposition/config file architecture.
You'll never get anywhere with trying to make it simpler for the
end user that a good
configuration WIZARD. Face it: at a MINIMUM, the end user will
HAVE to understand his
MIDI hardware, and he will HAVE to go through a configuration process at least
ONCE per
different organ definition disposition. Even Hauptwerk does not
make it simpler than
this! In fact, Hauptwerk's configuration wizard could probably be used as a
functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the
scope,
channel and device of every keyboard and continuous controller (swell).
Any user who wants to be "lazier" than this probably does not deserve much
consideration
from this forum. If Sven were trying to make money from selling
jOrgan licenses,
he might
be inclined to bend-over-backwards for the ultra-lazy dummy. But
given the monetary
compensation involved, I would be surprised if any serious help would be
forthcoming for
any end user who is unwilling to work through a configuration
wizard at least once
for
each distinct disposition that he wants to use.
CLW
------------------------------------------------------------------------
Post by Roy Radford
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Post by Roy Radford
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
-----Inline Attachment Follows-----
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Post by Roy Radford
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-21 21:56:54 UTC
Permalink
Geert, in looking at my reply to Lynn, I was not aware that you had made any comment concerning it. I guess when we native speakers of English get off on a tangent, I sometimes do not expect that the non-native speakers of English will have a thorough appreciation for what we are complaining about are otherwise commenting on.
In this case, I am not certain that the exact same kind of language problems exist in Germany or the Netherlands or the other countries of Europe. On the other hand,
“political correctness,” a euphemism for the inability, particularly by politicians, to treat a subject with clarity based on a traditional understanding of word meanings and definitions and an understanding and acceptance of the legal basis for distinction for purposes of proper governance instead of pandering for votes at the ballot box, is becoming a problem in American society and may be a problem for you Europeans also, I don’t know. You may look at us and say that the “chickens have finally come home to roost,” but there are many of us who resist the tendency of certain parts of our society to so fundamentally change our system so that there is no accountability and, thus, invalidate the morality and ethics which must pervade a society in order for there to be justice. The ability to communicate with meaning and understanding is essential and we are merely decrying the loss of that.
In response to your question, I don’t know what you said and so I don’t know if you made yourself clear enough or not. There was a time when gender, for example, referred to a noun in a foreign language as being either masculine or feminine or neuter. Now it has the connotation of the sex of a person. This is an example of a recent change in the language with regard to a new meaning being assigned to a word that may have that implied meaning, but is not normally used express that idea.

John B.

From: orgel jeux
Sent: Thursday, April 21, 2011 5:31 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab

John,

As you only answwered Lynn, I guess you do not agree with what I said?/

or did I not make myself clear enough?/

greetings,

Geert


2011/4/21 John Beach <***@fairpoint.net>

Absolutely right! For example, "If God had wanted man to fly He would have
given him wings." "Man," in this case, refers to humankind, male or
female. "Him" is the objective pronoun that, in this case, is applicable to
women as part of humankind as well. The "politically correct" crowd have
done little but confuse understanding by a distinct lack of precision in
communication based on traditional definition. As a trained linguist, I
find this particularly distasteful. It is difficult enough to deal with the
idiomatic expressions which are unique to languages and need to be
translated, to say nothing of the contemporary nuances of meaning that have
been co-opted by the liberals in re-definitions and which leave us all in a
state of utter confusion. Implication and inference are difficult and
varied enough without adding a third dimension of ethereal supposition.
So much for the "egg" and "Mother God."
John B.





-----Original Message-----
From: Lynn Walls
Sent: Thursday, April 21, 2011 2:53 PM
To: jorgan-***@lists.sourceforge.net

Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab

Roy,

I attended grammar school in the 1960s. There we learned that the personal
pronouns "he"
and "him" and suffix "-man" stood for BOTH male and female whenever a
general
(non-specific) person was being referenced. This definition has always been
good enough
for me, and I have never bought into the extremely awkward "he/she",
"him/her", "-person"
terminology. Those constructs do not add any meaning to the dialog, and
only serve to
appease the "politically correct" crowd.

CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module
abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Date: Thursday, 21 April, 2011, 19:27
I agree with Lynn.
Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept
just download and install.
jOrgan is not for pipe organs only. Remember my piano/strings dispo. There's a hold
stop like the ones found on synths.
I use jorgan to control big samplers with any type of instrument
loaded in 16 channels
at least.
Matt was right that there are users with 4:3 screens and is hard for
them when a dispo
creator releases for 16:9. Two screen versions by the creator is the
solution, not in
software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect
depending on the organ,
or even the synthesizer (!) yes. I got one dispo with two keybords for
conrollers, one
for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the
other for a
61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
Configuration wizard is very good as it is IMHO, it's up to the
disposition creator to
work harder to cover as many users' needs as he can (I'm not sayin' she as we don't
have any lady dispo creator... yet).
As time goes by and we know each other better, more or less we know
how our physical
consoles are, add to that this jOrgan-life-pictures topics (gooood!),
so dispositions
can be this way for work for the most of us.
A data base of "Registered Users Physical consoles and/or kbd controllers" would be
very useful I'm thinkin', so I would know for whom I'm gonna make things.
Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?
Since I know he will love it and use it in Church !!
Or someone with a 3man console that he/she needs some stops for the 3rd man and
he/she's got a two man dispo.
Private e-mails are good for this. Why not ask ? Is it possible to? Then it's up to
the creator if he will, as time and obligations permits. Seems like an
after sales
concept, I know, but here we're a kinda familly, or community.
Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea,
many others would
beneffit from, but, I didn't know how to do it, he did, I uploaded this alternate
version and so on.
My point is we can work together in some level and cannot expect
everything from Sven.
Ah, some good news. Hauptwerk 4 is released and guess what : it has a
midi recorder in
it..... he he, jOrgan has it for sooooo long, also F11 full screen
(now?) and Midi out
for all versions :-) and some customizing features......
Beyond jokes, HW4 is powerfull but all the above proves that jOrgan
leads the way in
some extremelly useful features.
Best
Panos
Yes...my two-layer (disposition file/config file) solution is
essentially intended
to help
the disposition developer --- NOT the end user. There would have
to be a .config file
tailored to each unique disposition. That is necessary because
each disposition would
potentially have a different number of keyboards, a different
number of swells, and a
different number of stops, couplers, trems and any other switches.
It would not be
feasible to define all these objects with any sort of "standard" nomenclature.
Just for
example, the manuals in classical/church organ terminology are named completely
differently than those of a theatre organ. And even within each of
those classes
of organ
the nomenclature often varies. And what about harpsichords, and
electronic synth rigs
(like Roy's) and other variants of keyboards and sound sources that jOrgan can
potentially
support? Don't assume that jOrgan is only only for pipe organs. So
don't try to
come up
just leave it up
to the
disposition developer to name those input and output devices in the most
meaningful way so
that when the Configuration WIZARD presents those names to the end
user, that end
user
will know what physical device needs to be connected to that name.
It is the robustness of the WIZARD that will help the "lazy" end
user -- NOT the
layered
disposition/config file architecture.
You'll never get anywhere with trying to make it simpler for the
end user that a good
configuration WIZARD. Face it: at a MINIMUM, the end user will
HAVE to understand his
MIDI hardware, and he will HAVE to go through a configuration process at least
ONCE per
different organ definition disposition. Even Hauptwerk does not
make it simpler than
this! In fact, Hauptwerk's configuration wizard could probably be used as a
functional
model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the
scope,
channel and device of every keyboard and continuous controller (swell).
Any user who wants to be "lazier" than this probably does not deserve much
consideration
from this forum. If Sven were trying to make money from selling
jOrgan licenses,
he might
be inclined to bend-over-backwards for the ultra-lazy dummy. But
given the monetary
compensation involved, I would be surprised if any serious help would be
forthcoming for
any end user who is unwilling to work through a configuration
wizard at least once
for
each distinct disposition that he wants to use.
CLW
------------------------------------------------------------------------
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
-----Inline Attachment Follows-----
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user


------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user




--------------------------------------------------------------------------------
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails


--------------------------------------------------------------------------------
Roy Radford
2011-04-21 19:16:51 UTC
Permalink
    Absolutely agree... Then again, no one has ever accused me of being Politically Correct!  


     Have fun,

         Roy.


--- On Thu, 21/4/11, Lynn Walls <***@gmail.com> wrote:

From: Lynn Walls <***@gmail.com>
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Thursday, 21 April, 2011, 19:53

Roy,

I attended grammar school in the 1960s.  There we learned that the personal pronouns "he"
and "him" and suffix "-man" stood for BOTH male and female whenever a general
(non-specific) person was being referenced.  This definition has always been good enough
for me, and I have never bought into the extremely awkward "he/she", "him/her", "-person"
terminology.  Those constructs do not add any meaning to the dialog, and only serve to
appease the "politically correct" crowd.

CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
     Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module
     abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
     Date: Thursday, 21 April, 2011, 19:27
     I agree with Lynn.
     Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept
     just download and install.
     jOrgan is not for pipe organs only. Remember my piano/strings dispo. There's a hold
     stop like the ones found on synths.
     I use jorgan to control big samplers with any type of instrument loaded in 16 channels
     at least.
     Matt was right that there are users with 4:3 screens and is hard for them when a dispo
     creator releases for 16:9. Two screen versions by the creator is the solution, not in
     software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
     And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect depending on the organ,
     or even the synthesizer (!) yes. I got one dispo with two keybords for conrollers, one
     for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the other for a
     61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
     Configuration wizard is very good as it is IMHO, it's up to the disposition creator to
     work harder to cover as many users' needs as he can (I'm not sayin' she as we don't
     have any lady dispo creator... yet).
     As time goes by and we know each other better, more or less we know how our physical
     consoles are, add to that this jOrgan-life-pictures topics (gooood!), so dispositions
     can be this way for work for the most of us.
     A data base of "Registered Users Physical consoles and/or kbd controllers" would be
     very useful I'm thinkin', so I would know for whom I'm gonna make things.
     Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?
     Since I know he will love it and use it in Church !!
     Or someone with a 3man console that he/she needs some stops for the 3rd man and
     he/she's got a two man dispo.
     Private e-mails are good for this. Why not ask ? Is it possible to? Then it's up to
     the creator if he will, as time and obligations permits. Seems like an after sales
     concept, I know, but here we're a kinda familly, or community.
     Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea, many others would
     beneffit from, but, I didn't know how to do it, he did, I uploaded this alternate
     version and so on.
     My point is we can work together in some level and cannot expect everything from Sven.
     Ah, some good news. Hauptwerk 4 is released and guess what : it has a midi recorder in
     it..... he he, jOrgan has it for sooooo long, also F11 full screen (now?) and Midi out
     for all versions :-) and some customizing features......
     Beyond jokes, HW4 is powerfull but all the above proves that jOrgan leads the way in
     some extremelly useful features.
     Best
     Panos
         Yes...my two-layer (disposition file/config file) solution is essentially intended
         to help
         the disposition developer --- NOT the end user. There would have to be a .config file
         tailored to each unique disposition. That is necessary because each disposition would
         potentially have a different number of keyboards, a different number of swells, and a
         different number of stops, couplers, trems and any other switches. It would not be
         feasible to define all these objects with any sort of "standard" nomenclature.
         Just for
         example, the manuals in classical/church organ terminology are named completely
         differently than those of a theatre organ. And even within each of those classes
         of organ
         the nomenclature often varies. And what about harpsichords, and electronic synth rigs
         (like Roy's) and other variants of keyboards and sound sources that jOrgan can
         potentially
         support? Don't assume that jOrgan is only only for pipe organs. So don't try to
         come up
         with some "standard" that only addresses pipe organs. Simply put: just leave it up
         to the
         disposition developer to name those input and output devices in the most
         meaningful way so
         that when the Configuration WIZARD presents those names to the end user, that end
         user
         will know what physical device needs to be connected to that name.
         It is the robustness of the WIZARD that will help the "lazy" end user -- NOT the
         layered
         disposition/config file architecture.
         You'll never get anywhere with trying to make it simpler for the end user that a good
         configuration WIZARD. Face it: at a MINIMUM, the end user will HAVE to understand his
         MIDI hardware, and he will HAVE to go through a configuration process at least
         ONCE per
         different organ definition disposition. Even Hauptwerk does not make it simpler than
         this! In fact, Hauptwerk's configuration wizard could probably be used as a
         functional
         model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the
         scope,
         channel and device of every keyboard and continuous controller (swell).
         Any user who wants to be "lazier" than this probably does not deserve much
         consideration
         from this forum. If Sven were trying to make money from selling jOrgan licenses,
         he might
         be inclined to bend-over-backwards for the ultra-lazy dummy. But given the monetary
         compensation involved, I would be surprised if any serious help would be
         forthcoming for
         any end user who is unwilling to work through a configuration wizard at least once
         for
         each distinct disposition that he wants to use.
         CLW
         ------------------------------------------------------------------------
     -----Inline Attachment Follows-----
     ------------------------------------------------------------------------------
     Fulfilling the Lean Software Promise
     Lean software platforms are now widely adopted and the benefits have been
     demonstrated beyond question. Learn why your peers are replacing JEE
     containers with lightweight application servers - and what you can gain
     from the move. http://p.sf.net/sfu/vmware-sfemails
     -----Inline Attachment Follows-----
     _______________________________________________
     jOrgan-user mailing list
     https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
orgel jeux
2011-04-21 19:27:33 UTC
Permalink
unknown
1970-01-01 00:00:00 UTC
Permalink
--00032555dc36aa67e304a172bbcf
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable

Typically Lynn......always so very logical in all his utterings!

But I LIKE to have in my mind - now and then - the pleasures of the
bi-sexual state of mankind, and that's why I honour it every now and then
with the double term.

Let's not get too far from the jOrgan-subject!

Geert
Post by Roy Radford
Absolutely agree... Then again, no one has ever accused me of being
Politically Correct!
Have fun,
Roy.
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab
Date: Thursday, 21 April, 2011, 19:53
Roy,
I attended grammar school in the 1960s. There we learned that the personal
pronouns "he"
and "him" and suffix "-man" stood for BOTH male and female whenever a
general
(non-specific) person was being referenced. This definition has always
been good enough
for me, and I have never bought into the extremely awkward "he/she",
"him/her", "-person"
terminology. Those constructs do not add any meaning to the dialog, and
only serve to
appease the "politically correct" crowd.
CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module
Post by Roy Radford
abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer
tab
Post by Roy Radford
Date: Thursday, 21 April, 2011, 19:27
I agree with Lynn.
Do not expect jOrgan (and any app) do anything in auto mode and us do
nothing exept
Post by Roy Radford
just download and install.
jOrgan is not for pipe organs only. Remember my piano/strings dispo.
There's a hold
Post by Roy Radford
stop like the ones found on synths.
I use jorgan to control big samplers with any type of instrument
loaded in 16 channels
Post by Roy Radford
at least.
Matt was right that there are users with 4:3 screens and is hard for
them when a dispo
Post by Roy Radford
creator releases for 16:9. Two screen versions by the creator is the
solution, not in
Post by Roy Radford
software. As 4xsound drivers versions (aka Direct, Asio, Jack,
WDMKS).
Post by Roy Radford
And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect
depending on the organ,
Post by Roy Radford
or even the synthesizer (!) yes. I got one dispo with two keybords
for conrollers, one
Post by Roy Radford
for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and
the other for a
Post by Roy Radford
61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
Configuration wizard is very good as it is IMHO, it's up to the
disposition creator to
Post by Roy Radford
work harder to cover as many users' needs as he can (I'm not sayin'
she as we don't
Post by Roy Radford
have any lady dispo creator... yet).
As time goes by and we know each other better, more or less we know
how our physical
Post by Roy Radford
consoles are, add to that this jOrgan-life-pictures topics (gooood!),
so dispositions
Post by Roy Radford
can be this way for work for the most of us.
A data base of "Registered Users Physical consoles and/or kbd
controllers" would be
Post by Roy Radford
very useful I'm thinkin', so I would know for whom I'm gonna make
things.
Post by Roy Radford
Example who to refuse Marco a Ped to Grt coupler with monophonic bass
?
Post by Roy Radford
Since I know he will love it and use it in Church !!
Or someone with a 3man console that he/she needs some stops for the
3rd man and
Post by Roy Radford
he/she's got a two man dispo.
Private e-mails are good for this. Why not ask ? Is it possible to?
Then it's up to
Post by Roy Radford
the creator if he will, as time and obligations permits. Seems like
an after sales
Post by Roy Radford
concept, I know, but here we're a kinda familly, or community.
Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea,
many others would
Post by Roy Radford
beneffit from, but, I didn't know how to do it, he did, I uploaded
this alternate
Post by Roy Radford
version and so on.
My point is we can work together in some level and cannot expect
everything from Sven.
Post by Roy Radford
Ah, some good news. Hauptwerk 4 is released and guess what : it has a
midi recorder in
Post by Roy Radford
it..... he he, jOrgan has it for sooooo long, also F11 full screen
(now?) and Midi out
Post by Roy Radford
for all versions :-) and some customizing features......
Beyond jokes, HW4 is powerfull but all the above proves that jOrgan
leads the way in
Post by Roy Radford
some extremelly useful features.
Best
Panos
Yes...my two-layer (disposition file/config file) solution is
essentially intended
Post by Roy Radford
to help
the disposition developer --- NOT the end user. There would have
to be a .config file
Post by Roy Radford
tailored to each unique disposition. That is necessary because
each disposition would
Post by Roy Radford
potentially have a different number of keyboards, a different
number of swells, and a
Post by Roy Radford
different number of stops, couplers, trems and any other
switches. It would not be
Post by Roy Radford
feasible to define all these objects with any sort of "standard"
nomenclature.
Post by Roy Radford
Just for
example, the manuals in classical/church organ terminology are
named completely
Post by Roy Radford
differently than those of a theatre organ. And even within each
of those classes
Post by Roy Radford
of organ
the nomenclature often varies. And what about harpsichords, and
electronic synth rigs
Post by Roy Radford
(like Roy's) and other variants of keyboards and sound sources
that jOrgan can
Post by Roy Radford
potentially
support? Don't assume that jOrgan is only only for pipe organs.
So don't try to
Post by Roy Radford
come up
just leave it up
Post by Roy Radford
to the
disposition developer to name those input and output devices in
the most
Post by Roy Radford
meaningful way so
that when the Configuration WIZARD presents those names to the
end user, that end
Post by Roy Radford
user
will know what physical device needs to be connected to that
name.
Post by Roy Radford
It is the robustness of the WIZARD that will help the "lazy" end
user -- NOT the
Post by Roy Radford
layered
disposition/config file architecture.
You'll never get anywhere with trying to make it simpler for the
end user that a good
Post by Roy Radford
configuration WIZARD. Face it: at a MINIMUM, the end user will
HAVE to understand his
Post by Roy Radford
MIDI hardware, and he will HAVE to go through a configuration
process at least
Post by Roy Radford
ONCE per
different organ definition disposition. Even Hauptwerk does not
make it simpler than
Post by Roy Radford
this! In fact, Hauptwerk's configuration wizard could probably be
used as a
Post by Roy Radford
functional
model if Sven wanted to enhance the jOrgan wizard to be able to
auto-detect the
Post by Roy Radford
scope,
channel and device of every keyboard and continuous controller
(swell).
Post by Roy Radford
Any user who wants to be "lazier" than this probably does not
deserve much
Post by Roy Radford
consideration
from this forum. If Sven were trying to make money from selling
jOrgan licenses,
Post by Roy Radford
he might
be inclined to bend-over-backwards for the ultra-lazy dummy. But
given the monetary
Post by Roy Radford
compensation involved, I would be surprised if any serious help
would be
Post by Roy Radford
forthcoming for
any end user who is unwilling to work through a configuration
wizard at least once
Post by Roy Radford
for
each distinct disposition that he wants to use.
CLW
------------------------------------------------------------------------
Post by Roy Radford
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Post by Roy Radford
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have
been
Post by Roy Radford
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can
gain
Post by Roy Radford
from the move. http://p.sf.net/sfu/vmware-sfemails
-----Inline Attachment Follows-----
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Post by Roy Radford
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
--00032555dc36aa67e304a172bbcf
Content-Type: text/html; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable

Typically Lynn......always so very logical in all his utterings!<br><br>But I LIKE to have in my mind - now and then - the pleasures of the bi-sexual state of mankind, and that&#39;s why I honour it every now and then with the double term.<br> <br>Let&#39;s not get too far from the jOrgan-subject!<br><br>Geert<br><br><div class="gmail_quote">2011/4/21 Roy Radford <span dir="ltr">&lt;<a href="mailto:***@yahoo.co.uk">***@yahoo.co.uk</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font: inherit;" valign="top">
    Absolutely agree... Then again, no one has ever accused me of being Politically Correct!   <img src="Loading Image..."><br><br><br>     Have fun,<br><br>         Roy.<br><br><br>
--- On <b>Thu, 21/4/11, Lynn Walls <i>&lt;<a href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>&gt;</i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> <br>From: Lynn Walls &lt;<a href="mailto:***@gmail.com" target="_blank">***@gmail.com</a>&gt;<br>Subject: Re: [jOrgan-user] OT. PROPOSAL: &quot;jOrgan Consoles&quot; &amp; &quot;jOrgan Dispositions&quot; module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab<div class="im">
<br>To: <a href="mailto:jorgan-***@lists.sourceforge.net" target="_blank">jorgan-***@lists.sourceforge.net</a><br></div>Date: Thursday, 21 April, 2011, 19:53<div><div></div><div class="h5"><br><br><div>Roy,<br><br>I attended grammar school in the 1960s. 
There we learned that the personal pronouns &quot;he&quot; <br>and &quot;him&quot; and suffix &quot;-man&quot; stood for BOTH male and female whenever a general <br>(non-specific) person was being referenced.  This definition has always been good enough <br>
for me, and I have never bought into the extremely awkward &quot;he/she&quot;, &quot;him/her&quot;, &quot;-person&quot; <br>terminology.� Those constructs do not add any meaning to the dialog, and only serve to <br>appease the &quot;politically correct&quot; crowd.<br> <br>CLW<br>--------------------------------------------------------------------<br><br>On 4/21/2011 2:42 PM, Roy Radford wrote:<br>&gt; &quot;I&#39;m not sayin&#39; she as we don&#39;t have any lady dispo creator... yet).&quot;<br>
&gt;<br>&gt; ...Come to think of it, do we have any ladies here at all?<br>&gt;<br>&gt;<br>&gt; Have fun,<br>&gt;<br>&gt; Roy.<br>&gt;<br>&gt;<br>&gt; --- On *Thu, 21/4/11, Panos Ghekas /&lt;<a href="http://mc/compose?to=***@yahoo.gr" target="_blank">***@yahoo.gr</a>&gt;/* wrote:<br>
&gt;<br>&gt;<br>&gt;     From: Panos Ghekas &lt;<a href="http://mc/compose?to=***@yahoo.gr" target="_blank">***@yahoo.gr</a>&gt;<br>&gt;     Subject: Re: [jOrgan-user] PROPOSAL: &quot;jOrgan Consoles&quot; &amp; &quot;jOrgan Dispositions&quot; module<br>
&gt;     abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab<br>&gt;     To: <a href="http://mc/compose?to=jorgan-***@lists.sourceforge.net" target="_blank">jorgan-***@lists.sourceforge.net</a><br>&gt;     Date: Thursday, 21 April, 2011, 19:27<br>
&gt;<br>&gt;     I agree with Lynn.<br>&gt;<br>&gt;     Do not expect jOrgan (and any app) do anything in auto mode and us do nothing exept<br>&gt;     just download and
install.<br>&gt;<br>&gt;     jOrgan is not for pipe organs only. Remember my piano/strings dispo. There&#39;s a hold<br>&gt;     stop like the ones found on synths.<br>&gt;     I use jorgan to control big samplers with any type of instrument loaded in 16 channels<br>
&gt;     at least.<br>&gt;<br>&gt;     Matt was right that there are users with 4:3 screens and is hard for them when a dispo<br>&gt;     creator releases for 16:9. Two screen versions by the creator is the solution, not in<br>
&gt;     software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).<br>&gt;     And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect depending on the organ,<br>&gt;     or even the synthesizer (!) yes. I got one dispo with two keybords for conrollers, one<br>
&gt; 
   for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the other for a<br>&gt;     61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.<br>&gt;<br>&gt;     Configuration wizard is very good as it is IMHO, it&#39;s up to the disposition creator to<br>
&gt;     work harder to cover as many users&#39; needs as he can (I&#39;m not sayin&#39; she as we don&#39;t<br>&gt;     have any lady dispo creator... yet).<br>&gt;<br>&gt;     As time goes by and we know each other better, more or less we know how our physical<br>
&gt;     consoles are, add to that this jOrgan-life-pictures topics (gooood!), so dispositions<br>&gt;     can be this way for work for the most of us.<br>&gt;     A data base of &quot;Registered Users Physical consoles and/or kbd controllers&quot; would be<br>
&gt; 
   very useful I&#39;m thinkin&#39;, so I would know for whom I&#39;m gonna make things.<br>&gt;     Example who to refuse Marco a Ped to Grt coupler with monophonic bass ?<br>&gt;     Since I know he will love it and use it in Church !!<br>
&gt;     Or someone with a 3man console that he/she needs some stops for the 3rd man and<br>&gt;     he/she&#39;s got a two man dispo.<br>&gt;<br>&gt;     Private e-mails are good for this. Why not ask ? Is it possible to? Then it&#39;s up to<br>
&gt;     the creator if he will, as time and obligations permits. Seems like an after sales<br>&gt;     concept, I know, but here we&#39;re a kinda familly, or community.<br>&gt;<br>&gt;     Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea, many others would<br>
&gt;     beneffit from, but, I
didn&#39;t know how to do it, he did, I uploaded this alternate<br>&gt;     version and so on.<br>&gt;<br>&gt;     My point is we can work together in some level and cannot expect everything from Sven.<br>&gt;<br>&gt;     Ah, some good news. Hauptwerk 4 is released and guess what : it has a midi recorder in<br>
&gt;     it..... he he, jOrgan has it for sooooo long, also F11 full screen (now?) and Midi out<br>&gt;     for all versions :-) and some customizing features......<br>&gt;     Beyond jokes, HW4 is powerfull but all the above proves that jOrgan leads the way in<br>
&gt;     some extremelly useful features.<br>&gt;<br>&gt;     Best<br>&gt;     Panos<br>&gt;<br>&gt;     --- Στις *Πέμ., 21/04/11, ο/η Lynn Walls /&lt;<a href="http://mc/compose?to=***@gmail.com" target="_blank">***@gmail.com</a>&gt;/* έγραψε:<br>
&gt;<br>&gt;         Yes...my two-layer (disposition file/config file) solution is essentially intended<br>&gt;         to help<br>&gt;         the disposition developer --- NOT the end user. There would have to be a .config file<br>
&gt;         tailored to each unique disposition. That is necessary because each disposition would<br>&gt;         potentially have a different number of keyboards, a different number of swells, and a<br>&gt;         different number of stops, couplers, trems and any other switches. It would not be<br>
&gt;         feasible to define all these objects with any sort of &quot;standard&quot;
nomenclature.<br>&gt;         Just for<br>&gt;         example, the manuals in classical/church organ terminology are named completely<br>&gt;         differently than those of a theatre organ. And even within each of those classes<br>
&gt;         of organ<br>&gt;         the nomenclature often varies. And what about harpsichords, and electronic synth rigs<br>&gt;         (like Roy&#39;s) and other variants of keyboards and sound sources that jOrgan can<br>
&gt;         potentially<br>&gt;         support? Don&#39;t assume that jOrgan is only only for pipe organs. So don&#39;t try to<br>&gt;         come up<br>&gt;         with some &quot;standard&quot; that only addresses pipe
organs. Simply put: just leave it up<br>&gt;         to the<br>&gt;         disposition developer to name those input and output devices in the most<br>&gt;         meaningful way so<br>&gt;         that when the Configuration WIZARD presents those names to the end user, that end<br>
&gt;         user<br>&gt;         will know what physical device needs to be connected to that name.<br>&gt;<br>&gt;         It is the robustness of the WIZARD that will help the &quot;lazy&quot; end user -- NOT the<br>&gt;         layered<br>
&gt;         disposition/config file architecture.<br>&gt;<br>&gt;         You&#39;ll never get anywhere with trying to make it simpler for the end user
that a good<br>&gt;         configuration WIZARD. Face it: at a MINIMUM, the end user will HAVE to understand his<br>&gt;         MIDI hardware, and he will HAVE to go through a configuration process at least<br>&gt;         ONCE per<br>
&gt;         different organ definition disposition. Even Hauptwerk does not make it simpler than<br>&gt;         this! In fact, Hauptwerk&#39;s configuration wizard could probably be used as a<br>&gt;         functional<br>
&gt;         model if Sven wanted to enhance the jOrgan wizard to be able to auto-detect the<br>&gt;         scope,<br>&gt;         channel and device of every keyboard and continuous controller (swell).<br>&gt;<br>&gt;     
   Any user who wants to be &quot;lazier&quot; than this probably does not deserve much<br>&gt;         consideration<br>&gt;         from this forum. If Sven were trying to make money from selling jOrgan licenses,<br>&gt;         he might<br>
&gt;         be inclined to bend-over-backwards for the ultra-lazy dummy. But given the monetary<br>&gt;         compensation involved, I would be surprised if any serious help would be<br>&gt;         forthcoming for<br>
&gt;         any end user who is unwilling to work through a configuration wizard at least once<br>&gt;         for<br>&gt;         each distinct disposition that he wants to use.<br>&gt;<br>&gt;     
   CLW<br>&gt;         ------------------------------------------------------------------------<br>&gt;<br>&gt;<br>&gt;     -----Inline Attachment Follows-----<br>&gt;<br>&gt;     ------------------------------------------------------------------------------<br>
&gt;     Fulfilling the Lean Software Promise<br>&gt;     Lean software platforms are now widely adopted and the benefits have been<br>&gt;     demonstrated beyond question. Learn why your peers are replacing JEE<br>&gt;     containers with lightweight application servers - and what you can gain<br>
&gt;     from the move. <a href="http://p.sf.net/sfu/vmware-sfemails" target="_blank">http://p.sf.net/sfu/vmware-sfemails</a><br>&gt;<br>&gt;     -----Inline Attachment
Follows-----<br>&gt;<br>&gt;     _______________________________________________<br>&gt;     jOrgan-user mailing list<br>&gt;     <a href="http://mc/compose?to=jOrgan-***@lists.sourceforge.net" target="_blank">jOrgan-***@lists.sourceforge.net</a> &lt;/mc/compose?to=<a href="http://mc/compose?to=jOrgan-***@lists.sourceforge.net" target="_blank">jOrgan-***@lists.sourceforge.net</a>&gt;<br>
&gt;     <a href="https://lists.sourceforge.net/lists/listinfo/jorgan-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/jorgan-user</a><br>&gt;<br>&gt;<br>&gt;<br>&gt; ------------------------------------------------------------------------------<br>
&gt; Fulfilling the Lean Software Promise<br>&gt; Lean software platforms are now widely adopted and the benefits have been<br>&gt; demonstrated beyond question. Learn
why your peers are replacing JEE<br>&gt; containers with lightweight application servers - and what you can gain<br>&gt; from the move. <a href="http://p.sf.net/sfu/vmware-sfemails" target="_blank">http://p.sf.net/sfu/vmware-sfemails</a><br>
&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; jOrgan-user mailing list<br>&gt; <a href="http://mc/compose?to=jOrgan-***@lists.sourceforge.net" target="_blank">jOrgan-***@lists.sourceforge.net</a><br>
&gt; <a href="https://lists.sourceforge.net/lists/listinfo/jorgan-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/jorgan-user</a><br><br>------------------------------------------------------------------------------<br>
Fulfilling the Lean Software Promise<br>Lean software platforms are now widely adopted and the benefits have been <br>demonstrated beyond question. Learn why your peers are replacing JEE <br>containers with lightweight
application servers - and what you can gain <br>from the move. <a href="http://p.sf.net/sfu/vmware-sfemails" target="_blank">http://p.sf.net/sfu/vmware-sfemails</a><br>_______________________________________________<br>
jOrgan-user mailing list<br><a href="http://mc/compose?to=jOrgan-***@lists.sourceforge.net" target="_blank">jOrgan-***@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/jorgan-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/jorgan-user</a><br>
</div></div></div></blockquote></td></tr></tbody></table><br>------------------------------------------------------------------------------<br>
Fulfilling the Lean Software Promise<br>
Lean software platforms are now widely adopted and the benefits have been<br>
demonstrated beyond question. Learn why your peers are replacing JEE<br>
containers with lightweight application servers - and what you can gain<br>
from the move. <a href="http://p.sf.net/sfu/vmware-sfemails" target="_blank">http://p.sf.net/sfu/vmware-sfemails</a><br>_______________________________________________<br>
jOrgan-user mailing list<br>
<a href="mailto:jOrgan-***@lists.sourceforge.net">jOrgan-***@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/jorgan-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/jorgan-user</a><br>
<br></blockquote></div><br><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>

--00032555dc36aa67e304a172bbcf--
Panos Ghekas
2011-04-21 22:54:36 UTC
Permalink
Not right I'm afraid.
We use to say man for every person male or female, as these terms come from ancient times where women were "res" in latin= thing, object and not considered as persons.It was a man's (=male) world , so many terms and idioms have male names.
I always use he/she in english, for this reason and as I use to it as a lawer...
In greek language we don't use man for person, but a word very much close to "human" = this too in english has the "man" element....In greek the word is "ÁÍÈÑÙÐÏÓ" witch exactly translates as "the one who looks up".Meaning that humans always looked to the sky to see God.
So, our grammar at 60's was wrong, as were all political systems then and more wrong the women's rights ! Ah, you see? : wo-man, there's the male in here ! is not a man is a wo man. Now does anybody know what "wo" means?Something inferior to man (male)? something better? (I doubt...)
Women's dominion came to an end when Druides (male) sent away woman priests of the Big Godess and took the lead. Also we left today with man followers/students of Jesus, what happened to those women following Him? And why Mary the Magdalene was recognised hundreds of years later, as it is known She was the best student of Jesus?We owe to pay our respect to the womankind for all those dark centuries IMHO.
Ok I stop here, as this can go far away and totaly outside this topic.
Hmmm, Sven I'm about to propose that faint idea of jOrgan-life, as a real everyday topic here. I think is good for many of us !
Best to allPanos

--- Óôéò ÐÝì., 21/04/11, ï/ç John Beach <***@fairpoint.net> Ýãñáøå:

Áðü: John Beach <***@fairpoint.net>
ÈÝìá: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Ðñïò: jorgan-***@lists.sourceforge.net
Çìåñïìçíßá: ÐÝìðôç, 21 Áðñßëéïò 2011, 20:03

Absolutely right!  For example, "If God had wanted man to fly He would have
given him wings."   "Man," in this case, refers to humankind, male or
female. "Him" is the objective pronoun that, in this case, is applicable to
women as part of humankind as well.   The "politically correct" crowd have
done little but confuse understanding by a distinct lack of precision in
communication based on traditional definition.  As a trained linguist, I
find this particularly distasteful.  It is difficult enough to deal with the
idiomatic expressions which are unique to languages and need to be
translated, to say nothing of the contemporary nuances of meaning that have
been co-opted by the liberals in re-definitions and which leave us all in a
state of utter confusion.   Implication and inference are difficult and
varied enough without adding a third dimension of ethereal supposition.
So much for the "egg" and "Mother God."
John B.




-----Original Message-----
From: Lynn Walls
Sent: Thursday, April 21, 2011 2:53 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab

Roy,

I attended grammar school in the 1960s.  There we learned that the personal
pronouns "he"
and "him" and suffix "-man" stood for BOTH male and female whenever a
general
(non-specific) person was being referenced.  This definition has always been
good enough
for me, and I have never bought into the extremely awkward "he/she",
"him/her", "-person"
terminology.  Those constructs do not add any meaning to the dialog, and
only serve to
appease the "politically correct" crowd.

CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
     Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module
     abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
     Date: Thursday, 21 April, 2011, 19:27
     I agree with Lynn.
     Do not expect jOrgan (and any app) do anything in auto mode and us do
nothing exept
     just download and install.
     jOrgan is not for pipe organs only. Remember my piano/strings dispo.
There's a hold
     stop like the ones found on synths.
     I use jorgan to control big samplers with any type of instrument
loaded in 16 channels
     at least.
     Matt was right that there are users with 4:3 screens and is hard for
them when a dispo
     creator releases for 16:9. Two screen versions by the creator is the
solution, not in
     software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
     And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect
depending on the organ,
     or even the synthesizer (!) yes. I got one dispo with two keybords for
conrollers, one
     for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the
other for a
     61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
     Configuration wizard is very good as it is IMHO, it's up to the
disposition creator to
     work harder to cover as many users' needs as he can (I'm not sayin'
she as we don't
     have any lady dispo creator... yet).
     As time goes by and we know each other better, more or less we know
how our physical
     consoles are, add to that this jOrgan-life-pictures topics (gooood!),
so dispositions
     can be this way for work for the most of us.
     A data base of "Registered Users Physical consoles and/or kbd
controllers" would be
     very useful I'm thinkin', so I would know for whom I'm gonna make
things.
     Example who to refuse Marco a Ped to Grt coupler with monophonic bass
?
     Since I know he will love it and use it in Church !!
     Or someone with a 3man console that he/she needs some stops for the
3rd man and
     he/she's got a two man dispo.
     Private e-mails are good for this. Why not ask ? Is it possible to?
Then it's up to
     the creator if he will, as time and obligations permits. Seems like an
after sales
     concept, I know, but here we're a kinda familly, or community.
     Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea,
many others would
     beneffit from, but, I didn't know how to do it, he did, I uploaded
this alternate
     version and so on.
     My point is we can work together in some level and cannot expect
everything from Sven.
     Ah, some good news. Hauptwerk 4 is released and guess what : it has a
midi recorder in
     it..... he he, jOrgan has it for sooooo long, also F11 full screen
(now?) and Midi out
     for all versions :-) and some customizing features......
     Beyond jokes, HW4 is powerfull but all the above proves that jOrgan
leads the way in
     some extremelly useful features.
     Best
     Panos
         Yes...my two-layer (disposition file/config file) solution is
essentially intended
         to help
         the disposition developer --- NOT the end user. There would have
to be a .config file
         tailored to each unique disposition. That is necessary because
each disposition would
         potentially have a different number of keyboards, a different
number of swells, and a
         different number of stops, couplers, trems and any other switches.
It would not be
         feasible to define all these objects with any sort of "standard"
nomenclature.
         Just for
         example, the manuals in classical/church organ terminology are
named completely
         differently than those of a theatre organ. And even within each of
those classes
         of organ
         the nomenclature often varies. And what about harpsichords, and
electronic synth rigs
         (like Roy's) and other variants of keyboards and sound sources
that jOrgan can
         potentially
         support? Don't assume that jOrgan is only only for pipe organs. So
don't try to
         come up
just leave it up
         to the
         disposition developer to name those input and output devices in
the most
         meaningful way so
         that when the Configuration WIZARD presents those names to the end
user, that end
         user
         will know what physical device needs to be connected to that name.
         It is the robustness of the WIZARD that will help the "lazy" end
user -- NOT the
         layered
         disposition/config file architecture.
         You'll never get anywhere with trying to make it simpler for the
end user that a good
         configuration WIZARD. Face it: at a MINIMUM, the end user will
HAVE to understand his
         MIDI hardware, and he will HAVE to go through a configuration
process at least
         ONCE per
         different organ definition disposition. Even Hauptwerk does not
make it simpler than
         this! In fact, Hauptwerk's configuration wizard could probably be
used as a
         functional
         model if Sven wanted to enhance the jOrgan wizard to be able to
auto-detect the
         scope,
         channel and device of every keyboard and continuous controller
(swell).
         Any user who wants to be "lazier" than this probably does not
deserve much
         consideration
         from this forum. If Sven were trying to make money from selling
jOrgan licenses,
         he might
         be inclined to bend-over-backwards for the ultra-lazy dummy. But
given the monetary
         compensation involved, I would be surprised if any serious help
would be
         forthcoming for
         any end user who is unwilling to work through a configuration
wizard at least once
         for
         each distinct disposition that he wants to use.
         CLW
         ------------------------------------------------------------------------
     -----Inline Attachment Follows-----
     ------------------------------------------------------------------------------
     Fulfilling the Lean Software Promise
     Lean software platforms are now widely adopted and the benefits have
been
     demonstrated beyond question. Learn why your peers are replacing JEE
     containers with lightweight application servers - and what you can
gain
     from the move. http://p.sf.net/sfu/vmware-sfemails
     -----Inline Attachment Follows-----
     _______________________________________________
     jOrgan-user mailing list
     https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user
John Beach
2011-04-22 02:23:43 UTC
Permalink
The scripture says that “she shall be called woman for she was taken from man,” according to the creation account in Genesis. It is probably from German.....
“vom Mann” (from the man) coming into English as “woman”. But it does make you wonder if it is a translation of the Hebrew and, whatever the word was for “woman,”
must mean “taken from man” in Hebrew. At least, that seems logical.

As far as the role of women is concerned, they are probably as fundamental in the work of the church today as they were at its inception in Antioch. On the other hand, Christ chose men as disciples for evangelism, NO woman, interestingly, and the story of Mary and Martha is one that has always interested me in terms of the sense of duty regarding the spiritual on the one hand with Mary and the more mundane kitchen chores with Martha on the other hand and the complaint against Mary by Martha. Generally women are seen as having the responsibility for cooking and cleanup chores and men are viewed in some Protestant sects, just as the Catholic Church maintains, as being the ones to whom the spiritual aspects of service are appointed and entrusted. Why this is so, does not appear to be entirely scriptural except with certain teachings of St. Paul regarding women and authority and why he had the point of view which he did and which has formed a basis for some degree of discrimination against women regarding specific areas of service in the church is interesting and certainly inconsistently practiced today, if it is even regarded as valid. But women have always had very important roles in church work as can be seen from the history of the orders of catholic nuns who educated, nursed and supported in many ways the work of the church in societies.


John B.


“
see? : wo-man, there's the male in here ! is not a man is a wo man. Now does anybody know what "wo" means?
Something inferior to man (male)? something better? (I doubt...)”


Women's dominion came to an end when Druides (male) sent away woman priests of the Big Godess and took the lead. Also we left today with man followers/students of Jesus, what happened to those women following Him? And why Mary the Magdalene was recognised hundreds of years later, as it is known She was the best student of Jesus?
We owe to pay our respect to the womankind for all those dark centuries IMHO.
Roy Radford
2011-04-21 23:04:05 UTC
Permalink
   Hi, Panos,

                  I've always understood that "woman" is a contraction of "woe of man".

    According to the Bible, the first woman was only created as a companion for the first man. All she actually did in that role was get him into trouble, thus creating a precedent which has survived unchanged down the ages!


     Have fun,

          Roy.


--- On Thu, 21/4/11, Panos Ghekas <***@yahoo.gr> wrote:

From: Panos Ghekas <***@yahoo.gr>
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Thursday, 21 April, 2011, 23:54

Not right I'm afraid.
We use to say man for every person male or female, as these terms come from ancient times where women were "res" in latin= thing, object and not considered as persons.It was a man's (=male) world , so many terms and idioms have male names.
I always use he/she in english, for this reason and as I use to it as a lawer...
In greek language we don't use man for person, but a word very much close to "human" = this too in english has the "man" element....In greek the word is "ΑΝΘΡΩΠΟΣ" witch exactly translates as "the one who looks up".Meaning that humans always looked to the sky to see God.
So, our grammar at 60's was wrong, as were all political systems then and more wrong the women's rights ! Ah, you see? : wo-man, there's the male in here ! is not a man is a wo man. Now does anybody know what "wo" means?Something inferior to man (male)? something
better? (I doubt...)
Women's dominion came to an end when Druides (male) sent away woman priests of the Big Godess and took the lead. Also we left today with man followers/students of Jesus, what happened to those women following Him? And why Mary the Magdalene was recognised hundreds of years later, as it is known She was the best student of Jesus?We owe to pay our respect to the womankind for all those dark centuries IMHO.
Ok I stop here, as this can go far away and totaly outside this topic.
Hmmm, Sven I'm about to propose that faint idea of jOrgan-life, as a real everyday topic here. I think is good for many of us !
Best to allPanos

--- Στις ΠέΌ., 21/04/11, ο/η John Beach <***@fairpoint.net> έγραψε:

Από: John Beach <***@fairpoint.net>
ΘέΌα: Re: [jOrgan-user] OT.
PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Προς: jorgan-***@lists.sourceforge.net
ΗΌεροΌηΜία: ΠέΌπτη, 21 Απρίλιος 2011, 20:03

Absolutely right!  For example, "If God had wanted man to fly He would have
given him wings."   "Man," in this case, refers to humankind, male or
female. "Him" is the objective pronoun that, in this case, is applicable to
women as part of humankind as well.   The "politically correct" crowd have
done little but confuse understanding by a distinct lack of precision in
communication based on traditional definition.  As a trained linguist, I
find this particularly distasteful.  It is difficult enough to deal with the
idiomatic expressions which are unique to languages and need to be
translated, to say
nothing of the contemporary nuances of meaning that have
been co-opted by the liberals in re-definitions and which leave us all in a
state of utter confusion.   Implication and inference are difficult and
varied enough without adding a third dimension of ethereal supposition.
So much for the "egg" and "Mother God."
John B.




-----Original Message-----
From: Lynn Walls
Sent: Thursday, April 21, 2011 2:53 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab

Roy,

I attended grammar school in the 1960s.  There we learned that the personal
pronouns "he"
and "him" and suffix "-man" stood for BOTH male
and female whenever a
general
(non-specific) person was being referenced.  This definition has always been
good enough
for me, and I have never bought into the extremely awkward "he/she",
"him/her", "-person"
terminology.  Those constructs do not add any meaning to the dialog, and
only serve to
appease the "politically correct" crowd.

CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
     Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module
     abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
     Date: Thursday, 21 April, 2011, 19:27
     I agree with Lynn.
     Do not expect jOrgan (and any app) do anything in auto mode and us do
nothing exept
     just download and install.
     jOrgan is not for pipe organs only. Remember my piano/strings dispo.
There's a
hold
Post by Roy Radford
     stop like the ones found on synths.
     I use jorgan to control big samplers with any type of instrument
loaded in 16 channels
     at least.
     Matt was right that there are users with 4:3 screens and is hard for
them when a dispo
     creator releases for 16:9. Two screen versions by the creator is the
solution, not in
     software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
     And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect
depending on the organ,
     or even the synthesizer (!) yes. I got one dispo with two keybords for
conrollers, one
     for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the
other for a
     61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
     Configuration wizard is very good as it is IMHO, it's up to the
disposition creator to
     work harder to cover as many users' needs as he can (I'm not sayin'
she as we don't
     have any lady dispo creator... yet).
     As time goes by and we know each other better, more or less we know
how our physical
     consoles are, add to that this jOrgan-life-pictures topics (gooood!),
so dispositions
     can be this way for work for the most of us.
     A data base of "Registered Users Physical consoles and/or kbd
controllers" would be
     very useful I'm
thinkin', so I would know for whom I'm gonna make
Post by Roy Radford
things.
     Example who to refuse Marco a Ped to Grt coupler with monophonic bass
?
     Since I know he will love it and use it in Church !!
     Or someone with a 3man console that he/she needs some stops for the
3rd man and
     he/she's got a two man dispo.
     Private e-mails are good for this. Why not ask ? Is it possible to?
Then it's up to
     the creator if he will, as time and obligations permits. Seems like an
after sales
     concept, I know, but here we're a kinda familly, or community.
     Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea,
many others would
 
   beneffit from, but, I didn't know how to do it, he did, I uploaded
Post by Roy Radford
this alternate
     version and so on.
     My point is we can work together in some level and cannot expect
everything from Sven.
     Ah, some good news. Hauptwerk 4 is released and guess what : it has a
midi recorder in
     it..... he he, jOrgan has it for sooooo long, also F11 full screen
(now?) and Midi out
     for all versions :-) and some customizing features......
     Beyond jokes, HW4 is powerfull but all the above proves that jOrgan
leads the way in
     some extremelly useful features.
     Best
     Panos
     ---
         Yes...my two-layer (disposition file/config file) solution is
essentially intended
         to help
         the disposition developer --- NOT the end user. There would have
to be a .config file
         tailored to each unique disposition. That is necessary because
each disposition would
         potentially have a different number of keyboards, a different
number of swells, and a
         different number of stops, couplers, trems and any other switches.
It would not be
   
     feasible to define all these objects with any sort of "standard"
Post by Roy Radford
nomenclature.
         Just for
         example, the manuals in classical/church organ terminology are
named completely
         differently than those of a theatre organ. And even within each of
those classes
         of organ
         the nomenclature often varies. And what about harpsichords, and
electronic synth rigs
         (like Roy's) and other variants of keyboards and sound sources
that jOrgan can
         potentially
         support? Don't assume that jOrgan is only only for pipe organs. So
don't try
to
Post by Roy Radford
         come up
just leave it up
         to the
         disposition developer to name those input and output devices in
the most
         meaningful way so
         that when the Configuration WIZARD presents those names to the end
user, that end
         user
         will know what physical device needs to be connected to that name.
         It is the robustness of the WIZARD that will help the "lazy" end
user -- NOT the
         layered
     
   disposition/config file architecture.
Post by Roy Radford
         You'll never get anywhere with trying to make it simpler for the
end user that a good
         configuration WIZARD. Face it: at a MINIMUM, the end user will
HAVE to understand his
         MIDI hardware, and he will HAVE to go through a configuration
process at least
         ONCE per
         different organ definition disposition. Even Hauptwerk does not
make it simpler than
         this! In fact, Hauptwerk's configuration wizard could probably be
used as a
         functional
         model if Sven wanted to enhance the jOrgan wizard to be
able to
Post by Roy Radford
auto-detect the
         scope,
         channel and device of every keyboard and continuous controller
(swell).
         Any user who wants to be "lazier" than this probably does not
deserve much
         consideration
         from this forum. If Sven were trying to make money from selling
jOrgan licenses,
         he might
         be inclined to bend-over-backwards for the ultra-lazy dummy. But
given the monetary
         compensation involved, I would be surprised if any serious help
would be
         forthcoming for
     
   any end user who is unwilling to work through a configuration
Post by Roy Radford
wizard at least once
         for
         each distinct disposition that he wants to use.
         CLW
         ------------------------------------------------------------------------
     -----Inline Attachment Follows-----
     ------------------------------------------------------------------------------
     Fulfilling the Lean Software Promise
     Lean software platforms are now widely adopted and the benefits have
been
     demonstrated beyond question. Learn why your peers are replacing JEE
     containers with
lightweight application servers - and what you can
Post by Roy Radford
gain
     from the move. http://p.sf.net/sfu/vmware-sfemails
     -----Inline Attachment Follows-----
     _______________________________________________
     jOrgan-user mailing list
     https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user



------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user

-----Inline Attachment Follows-----
Panos Ghekas
2011-04-21 23:10:26 UTC
Permalink
Yep.But the Bible was written by men too........How conveniant to say that woman is just a companion..... meaning she's just for the pleasure and nothing else. Hmmmm....
Fun we gotPanos
--- Óôéò ÐÝì., 21/04/11, ï/ç Roy Radford <***@yahoo.co.uk> Ýãñáøå:

Áðü: Roy Radford <***@yahoo.co.uk>
ÈÝìá: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Ðñïò: jorgan-***@lists.sourceforge.net
Çìåñïìçíßá: ÐÝìðôç, 21 Áðñßëéïò 2011, 23:04

   Hi, Panos,

                  I've always understood that "woman" is a contraction of "woe of man".

    According to the Bible, the first woman was only created as a companion for the first man. All she actually did in that role was get him into trouble, thus creating a precedent which has survived unchanged down the ages!


     Have fun,

          Roy.


--- On Thu, 21/4/11, Panos Ghekas <***@yahoo.gr> wrote:

From: Panos Ghekas
<***@yahoo.gr>
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Thursday, 21 April, 2011, 23:54

Not right I'm afraid.
We use to say man for every person male or female, as these terms come from ancient times where women were "res" in latin= thing, object and not considered as persons.It was a man's (=male) world , so many terms and idioms
have male names.
I always use he/she in english, for this reason and as I use to it as a lawer...
In greek language we don't use man for person, but a word very much close to "human" = this too in english has the "man" element....In greek the word is "ÁÍÈÑÙÐÏÓ" witch exactly translates as "the one who looks up".Meaning that humans always looked to the sky to see God.
So, our grammar at 60's was wrong, as were all political systems then and more wrong the women's rights ! Ah, you see? : wo-man, there's the male in here ! is not a man is a wo man. Now does anybody know what "wo" means?Something inferior to man (male)? something
better? (I doubt...)
Women's dominion came to an end when Druides (male) sent away woman priests of the Big Godess and took the lead. Also we left today with man followers/students of Jesus, what happened to those women following Him? And why Mary the Magdalene was recognised hundreds of years later, as it is known She was the best student of Jesus?We owe to pay our respect to the womankind for all those dark centuries IMHO.
Ok I stop here, as this can go far away and totaly outside this topic.
Hmmm, Sven I'm about to propose that faint idea of jOrgan-life, as a real everyday topic here. I think is good for many of us !
Best to allPanos

--- Óôéò ÐÝì., 21/04/11, ï/ç John Beach <***@fairpoint.net> Ýãñáøå:

Áðü: John Beach <***@fairpoint.net>
ÈÝìá: Re:
[jOrgan-user] OT.
PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
Ðñïò: jorgan-***@lists.sourceforge.net
Çìåñïìçíßá: ÐÝìðôç, 21 Áðñßëéïò 2011, 20:03

Absolutely right!  For example, "If God had wanted man to fly He would have
given him wings."   "Man," in this case, refers to humankind, male or
female. "Him" is the objective pronoun that, in this case, is applicable to
women as part of humankind as well.   The "politically correct" crowd have
done little but confuse understanding by a distinct lack of precision in
communication based on traditional definition.  As a trained linguist, I
find this particularly distasteful.  It is difficult enough to deal with the
idiomatic expressions which are unique to languages and need to be

translated, to say
nothing of the contemporary nuances of meaning that have
been co-opted by the liberals in re-definitions and which leave us all in a
state of utter confusion.   Implication and inference are difficult and
varied enough without adding a third dimension of ethereal supposition.
So much for the "egg" and "Mother God."
John B.




-----Original Message-----
From: Lynn Walls
Sent: Thursday, April 21, 2011 2:53 PM
To: jorgan-***@lists.sourceforge.net
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan
Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth
costumizer tab

Roy,

I attended grammar school in the 1960s.  There we learned that the personal
pronouns "he"
and "him" and suffix "-man" stood for BOTH male
and female whenever a
general
(non-specific) person was being referenced.  This definition has always been
good enough
for me, and I have never bought into the extremely awkward "he/she",
"him/her", "-person"
terminology.  Those constructs do not add any meaning to the dialog, and
only serve to
appease the "politically correct" crowd.

CLW
--------------------------------------------------------------------
Post by Roy Radford
"I'm not sayin' she as we don't have any lady dispo creator... yet)."
...Come to think of it, do we have any ladies here at all?
Have fun,
Roy.
 
   Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan
Post by Roy Radford
Dispositions" module
     abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
     Date: Thursday, 21 April, 2011, 19:27
     I agree with Lynn.
     Do not expect jOrgan (and any app) do anything in auto mode and us do
nothing exept
     just download and install.
     jOrgan is not for pipe organs only. Remember my piano/strings dispo.
There's a
hold
Post by Roy Radford
     stop like the ones found on synths.
     I use jorgan to control big samplers with any type of instrument
loaded in 16 channels
     at least.
     Matt was right that there are users with 4:3 screens and is hard for
them when a dispo
     creator releases for 16:9. Two screen versions by the creator is the
solution, not in
     software. As 4xsound drivers versions (aka Direct, Asio, Jack, WDMKS).
     And creating Xmanual versions too, aka 1m, 1m/p, 2m, 2m/p ect
depending on the organ,
     or even the synthesizer (!) yes. I got one dispo with two keybords for
conrollers, one
     for an 88 piano type , engaging piano,rhodes,CP80,Clavinet ect and the
other for a
     61keys synth type engaging OB8, Moog, Prophet5 ect stops on console.
     Configuration wizard is very good as it is IMHO, it's up to the
disposition creator to
     work harder to cover as many users' needs as he can (I'm not sayin'
she as we don't
     have any lady dispo creator... yet).
     As time goes by and we know each other better, more or less we know
how our physical
     consoles are, add to that this jOrgan-life-pictures topics (gooood!),
so dispositions
     can be this way for work for the most of us.
     A data base of "Registered Users Physical consoles and/or kbd
controllers" would be
     very useful I'm
thinkin', so I would know for whom I'm gonna make
Post by Roy Radford
things.
     Example who to refuse Marco a Ped to Grt coupler with monophonic bass
?
     Since I know he will love it and use it in Church !!
     Or someone with a 3man console that he/she needs some stops for the
3rd man and
     he/she's got a two man dispo.
     Private e-mails are good for this. Why not ask ? Is it possible to?
Then it's up to
     the creator if he will, as time and obligations permits. Seems like an
after sales
     concept, I know, but here we're a kinda familly, or community.
     Remember, Erik wanted a multi out Oberhausbergen. Yeah, good idea,
many others would
 
   beneffit from, but, I didn't know how to do it, he did, I uploaded
Post by Roy Radford
this alternate
     version and so on.
     My point is we can work together in some level and cannot expect
everything from Sven.
     Ah, some good news. Hauptwerk 4 is released and guess what : it has a
midi recorder in
     it..... he he, jOrgan has it for sooooo long, also F11 full screen
(now?) and Midi out
     for all versions :-) and some customizing features......
     Beyond jokes, HW4 is powerfull but all the above proves that jOrgan
leads the way in
     some extremelly useful features.
     Best
     Panos
     ---
         Yes...my two-layer (disposition file/config file) solution is
essentially intended
         to help
         the disposition developer --- NOT the end user. There would have
to be a .config file
         tailored to each unique disposition. That is necessary because
each disposition would
         potentially have a different number of keyboards, a different
number of swells, and a
         different number of stops, couplers, trems and any other switches.
It would not be
   
     feasible to define all these objects with any sort of "standard"
Post by Roy Radford
nomenclature.
         Just for
         example, the manuals in classical/church organ terminology are
named completely
         differently than those of a theatre organ. And even within each of
those classes
         of organ
         the nomenclature often varies. And what about harpsichords, and
electronic synth rigs
         (like Roy's) and other variants of keyboards and sound sources
that jOrgan can
         potentially
         support? Don't assume that jOrgan is only only for pipe organs. So
don't try
to
Post by Roy Radford
         come up
just leave it up
         to the
         disposition developer to name those input and output devices in
the most
         meaningful way so
         that when the Configuration WIZARD presents those names to the end
user, that end
         user
         will know what physical device needs to be connected to that name.
         It is the robustness of the WIZARD that will help the "lazy" end
user -- NOT the
         layered
     
   disposition/config file architecture.
Post by Roy Radford
         You'll never get anywhere with trying to make it simpler for the
end user that a good
         configuration WIZARD. Face it: at a MINIMUM, the end user will
HAVE to understand his
         MIDI hardware, and he will HAVE to go through a configuration
process at least
         ONCE per
         different organ definition disposition. Even Hauptwerk does not
make it simpler than
         this! In fact, Hauptwerk's configuration wizard could probably be
used as a
         functional
         model if Sven wanted to enhance the jOrgan wizard to be
able to
Post by Roy Radford
auto-detect the
         scope,
         channel and device of every keyboard and continuous controller
(swell).
         Any user who wants to be "lazier" than this probably does not
deserve much
         consideration
         from this forum. If Sven were trying to make money from selling
jOrgan licenses,
         he might
         be inclined to bend-over-backwards for the ultra-lazy dummy. But
given the monetary
         compensation involved, I would be surprised if any serious help
would be
         forthcoming for
     
   any end user who is unwilling to work through a configuration
Post by Roy Radford
wizard at least once
         for
         each distinct disposition that he wants to use.
         CLW
         ------------------------------------------------------------------------
     -----Inline Attachment Follows-----
     ------------------------------------------------------------------------------
     Fulfilling the Lean Software Promise
     Lean software platforms are now widely adopted and the benefits have
been
     demonstrated beyond question. Learn why your peers are replacing JEE
     containers with
lightweight application servers - and what you can
Post by Roy Radford
gain
     from the move. http://p.sf.net/sfu/vmware-sfemails
     -----Inline Attachment Follows-----
     _______________________________________________
     jOrgan-user mailing list
     https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software
Promise
Post by Roy Radford
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question.
Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user



------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user

-----Inline Attachment Follows-----

------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
-----Inline Attachment Follows-----

_______________________________________________
jOrgan-user mailing list
jOrgan-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jorgan-user

-----Áêïëïõèåß óõíçììÝíï-----
Lynn Walls
2011-04-21 23:58:14 UTC
Permalink
Absolutely not, Panos!

She also feeds the infants (note the special anatomy that was especially designed for this
purpose).

CLW
---------------------------------------------------------------------------
Post by Panos Ghekas
Yep.
But the Bible was written by men too........
How conveniant to say that woman is just a companion..... meaning she's just for the
pleasure and nothing else. Hmmmm....
Marco Francesco
2011-04-22 00:28:20 UTC
Permalink
Hi Lynn,

Really? Oh! But I thought......

Marco

PS Even the absence of women is creating a stir!!!!
Post by Lynn Walls
Absolutely not, Panos!
She also feeds the infants (note the special anatomy that was especially designed for this
purpose).
CLW
--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3467148.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
orgel jeux
2011-04-22 09:14:06 UTC
Permalink
Ok,ok,

my use of the term he ( she) has pulled the lid enough now!! ( Don't know if
this expression is good English).

I enjoyed it very much, and, besides, it's good for my understanding of the
language....

Greetings,

Geert
Post by Marco Francesco
Hi Lynn,
Really? Oh! But I thought......
Marco
PS Even the absence of women is creating a stir!!!!
Post by Lynn Walls
Absolutely not, Panos!
She also feeds the infants (note the special anatomy that was especially
designed for this
purpose).
CLW
--
http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3467148.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Roy Radford
2011-04-22 00:03:45 UTC
Permalink
  "note the special anatomy that was especially designed for this
purpose"

   Oh, I DO, I DO!  


   I remember accidentally bumping into a well-endowed girl who fortunately shared my sense of humour as I said,

    "Whoops, crunch... Or should I say squelch!"  


        Have fun,

            Roy.


--- On Fri, 22/4/11, Lynn Walls <***@gmail.com> wrote:

From: Lynn Walls <***@gmail.com>
Subject: Re: [jOrgan-user] OT. PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Friday, 22 April, 2011, 0:58

Absolutely not, Panos!

She also feeds the infants (note the special anatomy that was especially designed for this
purpose).

CLW
---------------------------------------------------------------------------
Post by Panos Ghekas
Yep.
But the Bible was written by men too........
How conveniant to say that woman is just a companion..... meaning she's just for the
pleasure and nothing else. Hmmmm....
Panos Ghekas
2011-04-22 00:49:14 UTC
Permalink
"This is a man's world, but would be nothing without a woman on"

James Brown said.....
Hey, do you think he did because of the possible lack of pleasure and someone raising kids?!!

and Kafka said "It's like a fight with women, that always ends in bed !"

fun, please have
Panos

--- Óôéò Ðáñ., 22/04/11, ï/ç Marco Francesco <***@gmail.com> Ýãñáøå:
Hi Lynn,

Really? Oh! But I thought......

Marco

PS Even the absence of women is creating a stir!!!!
Post by Lynn Walls
Absolutely not, Panos!
She also feeds the infants (note the special anatomy that was especially
designed for this
purpose).
CLW
Roy Radford
2011-04-22 12:32:49 UTC
Permalink
  Hi, Berndt,

                  As a more-or-less outsider on this sort of thing it occurs to me that that is just the problem. The job consists of a myriad of little things, rather than a few big things to get your head around!


      Have fun,

          Roy.


--- On Fri, 22/4/11, BCA <***@free-artists.net> wrote:

From: BCA <***@free-artists.net>
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Friday, 22 April, 2011, 11:45

Hi Matt,

I find those little developments by you very interesting, this could be very
helpful for the disposition development. Keeping this in mind, I shall
research which such questions rise in me during the process. There are many
little things... Do you remember Lynn has made something in a similar way,
some time ago?

Many thanks and Regards
Bernd.

--
View this message in context: http://jorgan.999862.n4.nabble.com/QUESTION-PROP-FluidSynth-costumizer-tab-tp3447481p3467759.html
Sent from the jOrgan - User mailing list archive at Nabble.com.
Roy Radford
2011-04-23 12:27:02 UTC
Permalink
Hi, Matt,

              "I have 10 combination elements for the Swell stops. How can I quickly
ensure that all 10 reference exactly the same stops and I didn't
accidentally leave one out in number 4?"

  I know this is only one item among many but I usually make one combination with all the correct references then clone the rest with CNTRL-D. That way you know they are all identical.

       Have fun,

           Roy.


--- On Sat, 23/4/11, Rick (greenfox) <***@gmail.com> wrote:

From: Rick (greenfox) <***@gmail.com>
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Saturday, 23 April, 2011, 11:48

Hello Matt

Your analyser sounds very interesting.

Regards
Rick
    - My personal input/output devices
    - My personal "messages" (in particular combination piston messages)
separately, and to be able to retain them across disposition releases, or insert them into new dispositions, and indeed I have scripts which do just this for me. This basically embodies what I think this entire discussion is about. The exact same thing is easily accomplished through the GUI. I'm just GUI averse - the mouse is the most damaging and cumbersome invention ever produced, IMHO.
Limiting my web app idea to this could possibly result in something useful. But the only possible way to accomplish any of this is through the hidden unique identifier of each element, internal to the disposition. So disposition developers would also have to be bound by a "contract" in order to use it - for instance, thou shalt not delete a keyboard and recreate it (thus losing the information that all users had stored about the keyboard). Forcing this contract on disposition developers seems to me to be a step backwards. Given the fact that nobody ever sees this unique identifier without looking at the resulting XML, it will be very difficult to even *define* this contract.
I don't think the reason the developer is silent on the issue is just because he's enjoying an Easter holiday.
- I have 10 combination elements for the Swell stops. How can I quickly ensure that all 10 reference exactly the same stops and I didn't accidentally leave one out in number 4?
- My "transpose" elements are supposed to reference all stops. How can I quickly ensure that they actually do?
- Does my "memory" element reference all of the things that it needs to? Did I leave something out?
- Did I remember to put a reasonable name/description on all of my elements, so that when I go looking for them in construct mode I don't see 4 elements called "2" and wonder which one belongs to the Swell division?
I find the construction of dispositions to be prone to human error, but involving things which a machine can do easily.
I have a series of transformations that input a disposition and kick me out a series of reports, and I can immediately identify shortcomings in many dispositions that are released. The transformations are, however, based on my own understanding of the format of the disposition file, which is still somewhat limited.
But this is probably a new thread to pick up on someday.
Cheers,
Matt
Post by BCA
Hi Matt,
I agree. A global default setup seems like trying to keep all the
mouseclicks jOrgan just is designed for, a "contradiction in terms".
WHICH parametres should be integrated into such a configuration file.
AFAICS those are only the channels for the keyboards, and perhaps the
settings for combination buttons.
...
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
jOrgan-user mailing list
https://lists.sourceforge.net/lists/listinfo/jorgan-user
Roy Radford
2011-04-23 12:31:56 UTC
Permalink
    Plus, of course, the eternal cracked gramophone record for all things computer, before you do anything new with an important file,

Back it up, click,
Back it up, click,
Back it up, click,

Back it up, click, ......


     Have fun,

         Roy.







--- On Sat, 23/4/11, Rick (greenfox) <***@gmail.com> wrote:

From: Rick (greenfox) <***@gmail.com>
Subject: Re: [jOrgan-user] PROPOSAL: "jOrgan Consoles" & "jOrgan Dispositions" module abstractions separation WAS: [QUESTION/PROP] FluidSynth costumizer tab
To: jorgan-***@lists.sourceforge.net
Date: Saturday, 23 April, 2011, 12:06

John

This "default 3.12" you mention is only on YOUR system.

When you installed jOrgan V3.12 you must have selected the following
function in the installation.  On the installation page "Select
Additional Tasks", you must have selected "Associate .disposition files".

In newer installations you have not selected this.  If you did select
this option in newer installations, then the newer installation would
become the "default" version of jOrgan that would open when you double
click on and .disposition file.

This is not an error or fault in jOrgan.  It is just that you have not
understood the results of selections you have made in various
installations.  Windows is not smart enough to know which version of
jOrgan you need to run when you double click a .disposition file.  It is
only as smart as the last time the installation told Windows to update
the association.

I agree it is a trap.  (The latest versions now warn you they are going
to update your file)  The only way to maintain the ability to use
previous versions of jOrgan is to avoid the habit of double clicking a
disposition file to open the program.  If you want an earlier version,
you must open the version of jOrgan first, then select the disposition
from within the program.  If you develop this habit you will not get caught.

Regards
Rick
    If you merely click on a
disposition, the default 3.12 will open the disposition and you get the "NOT
A VALID jOrgan DISPOSITION,"  which, of course, it not true.  It just won't
open in the 3.12 version of jOrgan since it is already upgraded to 3.13 beta
7, for example.
John B.
Loading...