GrandOrgue Limitations #1628
Bumblebee001
started this conversation in
General
GrandOrgue Limitations
#1628
Replies: 4 comments
-
|
Hi,
I can see where you’re coming from.
As developers, we face several challenges, no matter what product we’re working on, I speak from experience over the many years. Usually, setting out to develop a product, the main aims are there, sometimes though, some elements get missed out or don’t work out as expected.
Here’s a good example… The work I used to do as a developer was based on accessibility for blind and sight impaired users relying on computer assisted music solutions, I started working for Apple long ago when VoiceOVer for MacOS 10.4 tiger was just starting it’s developer phase, so when I was taken on, I had to start learning a few new tricks, it was tiring, but worth it. Over the years, VoiceOver and MacOS changed for the better in various ways, but at the same time, within the last 6 years, it’s changed, some elements for the better, some for the worst but that’s since I had to retire due to health reasons.
Accessibility development is a challenge in itself because most of the frameworks are there, but general level developers miss out those elements in part due to not potentially seeing the need to implement accessibility components in to software, this is one of those headaches I come across a lot. Now, I work for a particular developer regarding an organ software platform and for the first time, I love what I’m doing, all-be-it from a much smaller scale and my last form of software based development work as I hang up my gloves, although I will still do some dev testing for them, etc, the headache still stands when it comes to making certain software products blind friendly, sadly, GrandOrgue is one of those products, but worse tha that, Hauptwerk, a platform by Milan Digital Audio who just grabs money, refuses to support accessibility development over the years and has the absolute nerve to block me from joining their hauptwerk forum to help them solve this matter, it goes to show their attitude to customers. so I gave them the push. It would be nice to witness the potential of some accessibility development and support for GrandOrgue, but the tools used are limited in this respect. if it could be recompiled and further tools and UI development could be made / achieved, GO would be a smash hit and a major threat to Hauptwerk.
That’s just my take on it, but I’ll say this. the team here are doing an amazing job, it takes a hell of a lot to get a package like this right, getting dependencies to fit together, UI elements to gel, organ libraries to update and behave how they should, etc.
I’ll admit this openly…
my dream organ software is an environment that doesn’t need fancy graphics, can be controlled by either touch panel displays or a midi console, a nice lightweight user interface, easy to navigate with a screen reader. Having the ability to easily design organ libraries without an intensive GUI would be a joy. What if for the display (GUI) you just built it as stop jambs in a simplified manner as switches rather than bitmaps, same with pistons and couplers, etc, remove the need for keyboards being viewed,, or create a UI that’s based purely on square coloured buttons where it’s more comfortable to a touch environment.
lew
… On 8 Aug 2023, at 11:05 am, Bumblebee001 ***@***.***> wrote:
Hi, if we want to improve GO further, one must read the comments on Piotr Grabowski's website. There have been attempts to create odfs for GO of sample-sets meant for HW but "limitations in GO" preclude the full functionality of these sets. I am not here to list what these limitations are but to highlight the need to investigate and explore ways where GO falls short compared to other popular programs that essentially do the same job.
We have Lars Palo currently developing an ODF generator (see: GOODF) that I am finding to be immensely helpful but it appears that even this software's development and features are limited to what GO "understands", "expects" and "does". Occasionally I do bring up issues but I do hope that a more proactive stance is adopted by those who are behind the upgrading of GO. Sometimes I am greatly discouraged by the negativity surrounding certain issues: (eg do we really need it? it is too complex.... or it would involve too much computing power..... etc). If they are possible and actually present in another software, there should certainly be a way to bring a feature to fruition in GO. GO and HW share a lot of similarities and one was an offshoot of the other..... so if there is a will there is a way (English Proverb).
One current difficulty I am experiencing is having a proper crescendo pedal that works without disrupting or conflicting with other features in a sample-set I am creating. This has slammed the brakes on my latest work as I have no idea how else to proceed. I cannot release this organ any time soon. Lars has helped a lot but he has other pressing committments. Besides, there is no easy or straightforward solutions known because GO is what it is at present.
Please note I have written this in good faith and I hope no one finds it offensive in any way. I love GO and I want it to be the best... and there's no better time than now!
—
Reply to this email directly, view it on GitHub <#1628>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATQDNKMROMVVWRHL5UPH4ALXUIFNPANCNFSM6AAAAAA3IHDAEY>.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@Bumblebee001 I have already done a subject on this with the full 'limitations' given by Piotr: |
Beta Was this translation helpful? Give feedback.
0 replies
-
@Bumblebee001 I don't remember the implementation Piotr has done for Alessandria organ but I think the crescendo pedal works well for that sample. I can check next week. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I have just communicated with Piotr. The version for GO lacks this feature for that sample
set. Actually none of his sets have this feature at all.
…On Tue, 08 Aug 2023 at 13:11, Denis Roussel (ACSONE) < ***@***.***> wrote:
One current difficulty I am experiencing is having a proper crescendo
pedal that works without disrupting or conflicting with other features in a
sample-set I am creating. This has slammed the brakes on my latest work as
I have no idea how else to proceed. I cannot release this organ any time
soon. Lars has helped a lot but he has other pressing committments.
Besides, there is no easy or straightforward solutions known because GO is
what it is at present.
@Bumblebee001 <https://github.com/Bumblebee001> I don't remember the
implementation Piotr has done for Alessandria organ but I think the
crescendo pedal works well for that sample. I can check next week.
—
Reply to this email directly, view it on GitHub
<#1628 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVM7NUP4WYMRSNDOFODYF3XUINFTANCNFSM6AAAAAA3IHDAEY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, if we want to improve GO further, one must read the comments on Piotr Grabowski's website. There have been attempts to create odfs for GO of sample-sets meant for HW but "limitations in GO" preclude the full functionality of these sets. I am not here to list what these limitations are but to highlight the need to investigate and explore ways where GO falls short compared to other popular programs that essentially do the same job.
We have Lars Palo currently developing an ODF generator (see: GOODF) that I am finding it to be immensely helpful but it appears that even this software's development and features are limited to what GO "understands", "expects" and "does". Occasionally I do bring up issues but I do hope that a more proactive stance is adopted by those who are behind the upgrading of GO. Sometimes I am greatly discouraged by the negativity surrounding certain issues: (eg do we really need it? it is too complex.... or it would involve too much computing power..... etc). If they are possible and actually present in another software, there should certainly be a way to bring a feature to fruition in GO. GO and HW share a lot of similarities and one was an offshoot of the other..... so if there is a will there is a way (English Proverb).
One current difficulty I am experiencing is having a proper crescendo pedal that works without disrupting or conflicting with other features in a sample-set I am creating. This has slammed the brakes on my latest work as I have no idea how else to proceed. I cannot release this organ any time soon. Lars has helped a lot but he has other pressing committments. Besides, there is no easy or straightforward solutions known because GO is what it is at present.
Please note I have written this in good faith and I hope no one finds it offensive in any way. I love GO and I want it to be the best... and there's no better time than now!
Beta Was this translation helpful? Give feedback.
All reactions