[RFC] Add an API to call GrandOrgue #1563
Comments
|
@rousseldenis Care to elaborate on your exact motifs and what you really wish to achieve? I have absolutely no idea what you mean by how Hauptwerk-based consoles manages things... But I sure can tell that your main advantage point has never, ever, been a prime concern in the development of GO, nor is it really in line with the base goals of the software as such. I'll elaborate myself on my last sentence. GO is not a general sample player software. It's highly specialized to allow virtual playing of pipe organ models. Most of the time we're talking (or should be talking) about digital models of real life organs. The general "user" of the software is mostly considered, and only required to be, a consumer of a product that a sample set producer (usually someone else) has created. That it's possible for an user to "edit" that product is a result mainly of the software being open sourced, not something that is generally encouraged. I also sense a deviation from the main direction of (historic) GO development in the desire to move to other control means than MIDI messages. It might be useful to consider that the actual GUI of GO was always considered to be of somewhat "less" importance than the actual sound producing model as such. The main goal was always to be able to play the organ sounds of an instrument you most likely couldn't visit in real life, but still wanted to enjoy the experience of getting as close to as possible. The GUI image could certainly help enriching the experience, and somewhat increase the impression of being at the original console - playing the modeled organ - that's for granted, but it was never the "main" thing. GO, as software, was always thought of as only part of that experience. Back in our minds as developers, we always thought that there would be a physical, MIDI driven, "organ like" console connected, from which the softwares sound production would be controlled. If that console is built DIY, or just using any existing MIDI capable digital instrument was not at all important - the development of GO tried to cater to all kind of needs (with extremely flexible and powerful MIDI possibilities/setup/detection etc). The implication of prioritizing that the user (as a consumer) should have easily accessible means to visually alter the GUI representation of an organ model is that: "looks are more important than sound". While I, as a sample set producer, spend lots of time (and I mean really lots of time) on creating that experience for others, and sometimes myself as user really enjoy the visual looks of organs in foreign places, I certainly hope that most enjoyment will always be playing the instrument on real keyboards and marvel at the sound of interesting real life pipe organ instruments. GO can after all be used from a MIDIfied organ console without any GUI once the basic setup of an organ is completed. And to be honest, my impression was that most developers thought that (that!) was way more important than "dynamically build stop controls interface", which I simply translate to "have the possibility to alter the looks of any GUI representation". |
|
@larspalo the intent here is not to modify the behavior of GrandOrgue AT ALL. The idea is to provide as a parallel layer on top of GO supplementary services in order to control the software (stops is a simple example). That layer is purely 'programmatic oriented' and is not altering in any manner the user experience. As in my example, this can be expressed by some simple ones:
This in order to provide advanced users supplementary way of controlling the software. |
|
Something like this could open a way of making grandorgue accessible in a degree for blind users. if the right components and environment are used in conjunction with support for screen readers.
worth a thought?
… On 5 Jun 2023, at 21:40, Denis Roussel (ACSONE) ***@***.***> wrote:
@larspalo <https://github.com/larspalo> the intent here is not to modify the behavior of GrandOrgue AT ALL.
The idea is to provide as a parallel layer on top of GO supplementary services in order to control the software (stops is a simple example).
That layer is purely 'programmatic oriented' and is not altering in any manner the user experience.
As in my example, this can be expressed by some simple ones:
list of stops
on/off stop X
etc....
This in order to provide advanced users supplementary way of controlling the software.
—
Reply to this email directly, view it on GitHub <#1563 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATQDNKP3T74BO6IVIQ6BXULXJY74TANCNFSM6AAAAAAY3JS4I4>.
You are receiving this because you are subscribed to this thread.
|
|
I like this idea. There are lack of some features of GrandOrgue GUI that are very difficult to add (for example, accessibility for blind users, discussed at #1553). Instead of implementing the full voice control of the console elements in it's owner GUI, it would be much easier to integrate it with an external voice control application. Rest API is used widely for communication of microservices in server-side applications. For now, it is rare used for desktop applications, because there are other standards (for example, COM on windows, DBus on linux, something exists on MacOs also). Unfortunally, all these standards are platform specific that contradicts the cross-platform nature of GrandOrgue. So using a server-side standard (REST) would be an acceptable option for us. If we decide to implement REST in GrandOrgue, the REST Message structure should be carefully thought out, well designed and well documented before the implementation because it will very hard to change it after. I suggest to start a separate discussion thread for this (not for discussing to do or not to do because it may be done in this issue, but for designing and discussing the structure of particular messages). |
Yes, that is what I had in mind when proposing this topic. This is intended to offer a new multiplatform interface and propose simple and reliable services (with auto-documentation provided by Swagger for instance).
That's why I thought about REST as it allows to implement a contract between the client and the server. This contract is clear for both parties and normally will never change (the implementation behind can). I'm currently testing some simple structure for its feasibility, but I have no doubt @oleg68 will do it in less time :-) I'm basing on this example https://github.com/ivanmejiarocha/micro-service |
|
Separating the functionality of GO into a client/server model is not trivial. In addition to the base software of GO, there's the separate layers of complexity of the sample sets, that provide most of the actual resources used, to factor in. The sample sets in turn can implement the same functionality in many different ways, totally up to the discretion of the producer. A simple example is the fact that the controlling "Stop" can be implemented in a multitude of ways before reaching the actual back end of the pipe samples. The "Stop" can be a [Stop999], a [Switch999], a [ReversiblePiston999] or right about any other element chosen as control - even any type of combination could potentially be used for that, so it's not that obvious what the resource actually is or how it's intended to be used. It would certainly be possible to completely re-design the GO to use a "server" back end that only load and provide the resources and then have a client that takes care of the rendering and interaction - but I'm highly doubtful if that's really a beneficial path to go. It could be expanding on the already existing basic idea of separating the "structural" organ parts from the displayed panels that now is mixed together in the odf. Regarding accessibility, I totally feel with the pain of those affected by visual impairment conditions. I've tested using the screen reader that's included in Ubuntu myself, and it's downright horrible to use generally - in right about any program or context! But before we ditch the normal desktop application as "very difficult" to make accessible, I suggest we'd really look into the available options that wxWidgets can provide (if compiled with such options) with for instance wxAccessible. |
|
I think that it’s possible with the widgets, I’m not experienced with that part of things.
Yes, the linux orca screen reader is disgusting at least, completely unusable at worst. Aeolus being a good example of the nightmare I faced when developing an accessible organ system.
I honestly reckon we could make GrandOrgue’s main UI screen reader friendly, is there anyone here who fancies giving this a try? I’m happy to help where I can from assessment, test and feedback, etc. I just don’t program anymore, I got out of the industry due to health concerns and now my health has taken a rather disturbing turn, I want to focus on a legacy that when I’ve gone, some achievements will be there through others with either my work or suggestions.
lew
… On 6 Jun 2023, at 12:50, larspalo ***@***.***> wrote:
Separating the functionality of GO into a client/server model is not trivial. In addition to the base software of GO, there's the separate layers of complexity of the sample sets, that provide most of the actual resources used, to factor in. The sample sets in turn can implement the same functionality in many different ways, totally up to the discretion of the producer. A simple example is the fact that the controlling "Stop" can be implemented in a multitude of ways before reaching the actual back end of the pipe samples. The "Stop" can be a [Stop999], a [Switch999], a [ReversiblePiston999] or right about any other element chosen as control - even any type of combination could potentially be used for that, so it's not that obvious what the resource actually is or how it's intended to be used.
It would certainly be possible to completely re-design the GO to use a "server" back end that only load and provide the resources and then have a client that takes care of the rendering and interaction - but I'm highly doubtful if that's really a beneficial path to go. It could be expanding on the already existing basic idea of separating the "structural" organ parts from the displayed panels that now is mixed together in the odf.
Regarding accessibility, I totally feel with the pain of those affected by visual impairment conditions. I've tested using the screen reader that's included in Ubuntu myself, and it's downright horrible to use generally - in right about any program or context! But before we ditch the normal desktop application as "very difficult" to make accessible, I suggest we'd really look into the available options that wxWidgets can provide (if compiled with such options) with for instance wxAccessible.
—
Reply to this email directly, view it on GitHub <#1563 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATQDNKKLLFZRD4ZSZID6EJDXJ4KQNANCNFSM6AAAAAAY3JS4I4>.
You are receiving this because you commented.
|
Redesign of GO is not necessary for making a REST API. I'd leave the current desktop application providing a GUI and implementing some logic, but I'd add the third control channel - REST to two existing now GUI/wx(mouse) and MIDI. It would not be a very complex task. At first we could start with very few control REST messages as @rousseldenis listed here. The primary intention for this API is not implement whe whole GUI, but only those features that are available now only with mouse and are not easy available with MIDI.
Yes, it also may be done, but it would require mush more efforts than REST. And for now, according to https://docs.wxwidgets.org/trunk/classwx_accessible.html
|
If you say so. Well, it's open source and who ever has the desire to develop anything is of course free to do so! When something is actually developed and can be evaluated we can judge better if it's truly of any benefit or not.
To be truly useful as an accessibility aid, all kinds of visually available controls must be implemented, even those that are defined in the sample sets. Basically everything on the screen that could be (by mouse) clicked must be available, and the all the dialogs must of course be accessible too. |
It is better to discuss such large enchancemenst before they are actually development.
At first I'd implement only the comination elements in the same way as they appear in the yaml file (of cause, in json format instead of yaml): the list of available combination elements and their current state and switching them on or off. So the start point is combinations, not the visual elements. At second we could be implement the list of registered organs and loading one of them. |
Generally, yes, I agree. But I'm not convinced that this really would be an enhancement until I can see the actual benefits (if any) from it, and also test that it won't bring performance penalties with it that could outweigh the possible gains. Still @rousseldenis has carefully avoided answering my first question: "Care to elaborate on your exact motifs and what you really wish to achieve?" Just saying "intended to offer a new multiplatform interface and propose simple and reliable services" means very little to me in itself. Interfacing with GO through http requests (a first criteria for REST APIs) instead of MIDI is not in itself an advantage as far as I can see it, which might not be very far I can unashamefully admit. |
Not instead of MIDI but instead of mouse clicks. MIDI would still exist. |
|
@rousseldenis
|
It was not intentional. Indeed the exact needs are still to be defined. But, I've faced a difficulty from the beginning using GO (and I use it mostly as end-user and intensively between 22:00 and... :-) ). Without having proper hardware (e.g. : touchscreen , physical shortcuts,...), it has always been difficult to command changes (I've acquired recently a third keyboard and it is easier). The way GO is built is tied to MIDI messages between GO and devices (in their diversity). You need to know what to send/receive and assign actions either on GO either on your device (or both). I agree that if configurations are well done, you can almost do whatever you expect. My point is (and @oleg68 said it above) that if you want to communicate in more structured language between GO and external world, you can achieve it in several ways. One can be shared libraries. But that can be very time consuming in both sides. One other is exposing on the network (hear here not necessary outside but on the machine local host) structures that allows to communicate with GO. The advantage of this solution is that almost everything (in almost all programming languages) can connect. This 'little' introduction leads to the answer you are expecting. This would allow users to have for example an android application on another tablet that can:
Or a dedicated application for blind people to command GO. Or for console builders who want to customize their interfaces with GrandOrgue and not the other one. If we implement this, that can open a way more GrandOrgue from the possibilities available now(tied to: interface, midi messages). As said too, that is a layer on top of GrandOrgue and should not alter the way it is working in any manner. Rest services are generally lightweight to implement(json data). The messages that are sent can be controlled (typed, constrained, ...). @larspalo I hope I've answered your questioning. If it's still not clear, I will be pleased to add further explanations :-) but I saw that @oleg68 has been interested in, so if he has more data to put on this @oleg68 I will check how boost imports can be limited to the strict necessary. IMHO using wxNet could be harsh to use as we maybe need to reinvent the wheel(as it provides only low level structures). |
|
Nothing beyond the accessibility perspective has so far been productive in this "issue", nor would be a major goal to pursue, in my opinion. As said, with proper MIDI hardware to complement the software of GO (which was always expected!) more or less everything can already be done by the user that can be reasonably expected. I personally think there are much more interesting paths to follow for the major development of GO. But again, feel free to follow whatever interest you have! In my experience, the development of any open source project is by "need". That is, you want something, and you're ready to invest some effort in having that done - then it's possible to do... Always be clear about what you really want though! |
I've put it in issues, but that's not definitely. Of course it's a new feature. I found that idea as interesting as I've put it here. But the path can be still long before the final implementation. Of course, I would have this feature as an option in configuration. Nevertheless, that's a low priority one. We can move forward on features that we need for day-to-day users :-) |
|
I´m trying to use some toolbar elements (Release tail, polyphony), but it can't be done via Midi. Could we add a Midi element for them? |
|
As an intermediate step, we could do a Python Gui Automation solution, commanding the GUI from outside (Not so robust) |
I'm wondering about what could be great to provide an API to control GrandOrgue from external tools from other means than MIDI messages.
The main advantage could be :
This because I was thinking how Hauptwerk-based consoles are managing their specialized touch interfaces for stops.
@oleg68 @larspalo
The idea could be providing REST services when GrandOrgue is running.
The text was updated successfully, but these errors were encountered: