jOrgan 3.8 beta5
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
jOrgan 3.8 beta5
by svenmeier
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5
by Brian S
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5
by pcstratman
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
My findings so far....
So, to the question "Does 3.8 affect the ACO in any way?" A "Record" element will have to be created.
Put it on the console and put a memory skin on it if you want to see the MIDI file name. I haven't played with the new memory functions, external files etc. Am I missing anything else? Paul From: svenmeier <sven@...> To: jorgan-user@... Sent: Thursday, October 29, 2009 2:44:49 AM Subject: [jOrgan-user] jOrgan 3.8 beta5 Hi all, I've uploaded beta5 of the upcoming jOrgan 3.8 with the following changes/new features: - several bugfixes - slight change in the recorder Midi file format - new configuration options for the recorder * choose between recording Combinations or recording those elements recalled by a combination * decide whether element names should be included in the Midi file - new executor extension, see http://jorgan.sf.net/disposition:executor Please give it a try. Let's try to fix remaining bugs and release 3.8 on Sunday. Have fun Sven -- View this message in context: http://www.nabble.com/jOrgan-3.8-beta5-tp26108161p26108161.html Sent from the jOrgan - User mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user |
|
|
|
Re: jOrgan 3.8 beta5
by svenmeier
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5
by drwilx
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5
by Roy Radford
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5
by svenmeier
::
Rate this Message:
|
|
|
|
jOrgan 3.8 beta5 - Question about memory file
by lwalls
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by greenfox Rick
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by svenmeier
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by svenmeier
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by pcstratman
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
What about this idea: Memory files would be disposition specific. Let's say I use ACO_4.0_3P-104_FS.disposition. The memory could be named ACO_4.0_3P-104_FS.memory00. A second memory file could be ACO_4.0_3P-104-FS.memory01. Then if I would "save as" something else, say ACO_4.1_3P-104_FS.disposition. Memories would then be saved for that disposition as ACO_4.1_3P-104_FS.memory00 .... etc. It would give the possibility of 100 different memory files for each disposition. (If you want 1,000 start with 000.) Am I understanding the system correctly? Paul From: svenmeier <sven@...> To: jorgan-user@... Sent: Fri, October 30, 2009 6:52:43 AM Subject: Re: [jOrgan-user] jOrgan 3.8 beta5 - Question about memory file Hi Lynn, > 1. When I make modifications to A.disposition, such as add or delete >Rank elements, is the X.memory file changed and saved so as to remain in >sync with the changed A.disposition file? The X.memory will stay untouched, it will just keep some outdated information. > 2. Then I change the Storage property of the Memory element to a new >filename: "Y.memory". When I exit jOrgan and the A.disposition is now >saved with the changed Storage property, will a NEW memory file named >"Y.memory" be created? Yes, if you choose a non-existent memory file, it will be saved as soon as you save the disposition. > 3. If I open the A.disposition again (which now specifies Y.memory), >and make changes such as add or delete ranks and/or stops, and then save >and exit, will those changes to A.disposition be synchronized to the >"Y.memory" file which it now references? What about the old A[X].memory >file which A.disposition no longer references? I assume it will no >longer be in sync with the modified A.disposition. X.memory still has its old state, but it's still useable with A.disposition. Added or removed elements do no harm. > 4. If I now open the changed A.disposition and change its Memory >element's Storage property BACK to the ORIGINAL "X.memory" file, will >that file no longer be usable with A.disposition since A.disposition was >modified and saved during a period when the X.memory file was not >referenced in the Storage property? X.memory doesn't know anything about the new elements and still has information about old elements - but this doesn't matter. > 5. Now, while jOrgan is closed/not running, I make a copy of >A.disposition and call it B.disposition. But remember, the copy, >B.disposition still references the same Y.memory file as its clone >original A.disposition. Then I make modifications to B.disposition and >save and exit jOrgan. Then I open A.disposition in jOrgan again and >make some different modifications to it, then save and exit. Has the >Y.memory file that is still referenced by the Memory element Storage >property of both the A.disposition and the B.disposition (which are now >quite different from each other) become unusable by one or the other (or >both) of those two dispositions? Y.memory is still useable with both dispositions. >If so, and one-to-many or many-to-one relationships between .disposition >files and .memory files is NOT POSSIBLE ... False assumption, see above. Note that the primary goal of memory files is to allow having multiple memories for a single disposition (not the other way around). And of course you don't lose your combination settings when a disposition developer publishes a new version of his disposition. Regards Sven -- View this message in context: http://old.nabble.com/jOrgan-3.8-beta5-tp26108161p26128762.html Sent from the jOrgan - User mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user |
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by svenmeier
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by pcstratman
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
My next question is: If the memory file's name is tied to the disposition, as I illustrated below, would "Save as" then be allowable? (By that I mean "Save as" wouldn't be problematic as it seems to be in 3.8?) Paul From: Sven Meier <sven@...> To: jorgan-user@... Sent: Fri, October 30, 2009 1:28:27 PM Subject: Re: [jOrgan-user] jOrgan 3.8 beta5 - Question about memory file Hi Paul, yes, you could use such a numbering scheme. Sven Pastor Paul C. Stratman wrote: > What about this idea: > > Memory files would be disposition specific. Let's say I use > ACO_4.0_3P-104_FS.disposition. The memory could be > named ACO_4.0_3P-104_FS.memory00. A second memory file could > be ACO_4.0_3P-104-FS.memory01. Then if I would "save as" something > else, say ACO_4.1_3P-104_FS.disposition. Memories would then be saved > for that disposition as ACO_4.1_3P-104_FS.memory00 .... etc. It > would give the possibility of 100 different memory files for each > disposition. (If you want 1,000 start with 000.) > > Am I understanding the system correctly? > > Paul > > ------------------------------------------------------------------------ > *From:* svenmeier <sven@...> > *To:* jorgan-user@... > *Sent:* Fri, October 30, 2009 6:52:43 AM > *Subject:* Re: [jOrgan-user] jOrgan 3.8 beta5 - Question about memory file > > > Hi Lynn, > > > 1. When I make modifications to A.disposition, such as add or delete > >Rank elements, is the X.memory file changed and saved so as to remain in > >sync with the changed A.disposition file? > > The X.memory will stay untouched, it will just keep some outdated > information. > > > 2. Then I change the Storage property of the Memory element to a new > >filename: "Y.memory". When I exit jOrgan and the A.disposition is now > >saved with the changed Storage property, will a NEW memory file named > >"Y.memory" be created? > > Yes, if you choose a non-existent memory file, it will be saved as soon as > you save the disposition. > > > 3. If I open the A.disposition again (which now specifies Y.memory), > >and make changes such as add or delete ranks and/or stops, and then save > >and exit, will those changes to A.disposition be synchronized to the > >"Y.memory" file which it now references? What about the old A[X].memory > >file which A.disposition no longer references? I assume it will no > >longer be in sync with the modified A.disposition. > > X.memory still has its old state, but it's still useable with > A.disposition. > Added or removed elements do no harm. > > > 4. If I now open the changed A.disposition and change its Memory > >element's Storage property BACK to the ORIGINAL "X.memory" file, will > >that file no longer be usable with A.disposition since A.disposition was > >modified and saved during a period when the X.memory file was not > >referenced in the Storage property? > > X.memory doesn't know anything about the new elements and still has > information about old elements - but this doesn't matter. > > > 5. Now, while jOrgan is closed/not running, I make a copy of > >A.disposition and call it B.disposition. But remember, the copy, > >B.disposition still references the same Y.memory file as its clone > >original A.disposition. Then I make modifications to B.disposition and > >save and exit jOrgan. Then I open A.disposition in jOrgan again and > >make some different modifications to it, then save and exit. Has the > >Y.memory file that is still referenced by the Memory element Storage > >property of both the A.disposition and the B.disposition (which are now > >quite different from each other) become unusable by one or the other (or > >both) of those two dispositions? > > Y.memory is still useable with both dispositions. > > >If so, and one-to-many or many-to-one relationships between .disposition > >files and .memory files is NOT POSSIBLE ... > > False assumption, see above. > > Note that the primary goal of memory files is to allow having multiple > memories for a single disposition (not the other way around). And of > course > you don't lose your combination settings when a disposition developer > publishes a new version of his disposition. > > Regards > > Sven > -- > View this message in context: > Sent from the jOrgan - User mailing list archive at Nabble.com > <http://Nabble.com>. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > jOrgan-user mailing list > jOrgan-user@... > <mailto:jOrgan-user@...> > https://lists.sourceforge.net/lists/listinfo/jorgan-user > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ------------------------------------------------------------------------ > > _______________________________________________ > jOrgan-user mailing list > jOrgan-user@... > https://lists.sourceforge.net/lists/listinfo/jorgan-user > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user |
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by svenmeier
::
Rate this Message:
|
|
|
|
Re: back to basics for a moment
by Aletcetc
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user |
|
|
|
Re: back to basics for a moment
by pcstratman
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
What I did was use an existing organ as a pattern. Osiris has hundreds of dispositions. So does the Aeolian-Skinner archive. Osiris occasionally will document the composition of a mixture. The ACO is modeled after Aeolian-Skinner Opus 150AB without the bombarde or solo divisions. Then I modified the disposition to what I thought was reasonable or usable. Sometimes you change your mind later. With the ACO I made few changes to the basic disposition. (Tons to the sounds and some other features.... but that's a different subject.) For me, the type of disposition determines the type of skin. I know it doesn't make the organ sound any better, but it does put you in the frame of mind for what you're playing. I wanted the Silbermann to sound and look
like the real thing, etc. Same with the Aeolian-Skinners and Schlickers. The look may be a minor point for some. For me its psychological and aesthetic. My touch screen is the stop board. The process of collecting or replicating sounds follows the selection of the disposition. Here too, it may be a long process of finding what sounds both accurate and interesting. I studied other dispositions, some of the free Hauptwerk/Myorgan/Grandorgue sets, along with "Encyclopedia of Organ Stops." I synthesized, tweaked, etc., until I came to what I liked. Then my tastes changed a little and I started to dislike the samples that had been stretched too far..... In coming to 4.0, there were some voices that I thought I was going to change, and then I went back to what I had. There's a point where some voices seem just right, or it seems they resist improvement. The beauty of
soundfonts and jOrgan is that if you want to change something, you can. If you want to add something, you can. If something doesn't work for you you can get rid of it. That's the flow chart. Have fun. Paul From: Al Schroer <pipes_on_the_horizon@...> To: jorgan-user@... Sent: Fri, October 30, 2009 5:54:50 PM Subject: Re: [jOrgan-user] back to basics for a moment
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ jOrgan-user mailing list jOrgan-user@... https://lists.sourceforge.net/lists/listinfo/jorgan-user |
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by Bernd Casper
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5 - Question about memory file
by svenmeier
::
Rate this Message:
|
|
|
|
Re: jOrgan 3.8 beta5
by Bernd Casper
::
Rate this Message:
|
| < Prev | 1 - 2 - 3 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
