Can GO output Stop Name text via MIDI SysExRaw messages?

[larspalo]

Originally posted 2021-07-19 12:50:56.802000 by gtc131 in GrandOrgue discussion forum on SourceForge

Can GO output Stop Name text via MIDI SysExRaw messages?

Such messages to be used by OLED display screens.

[larspalo]

Originally posted 2021-07-21 06:12:32.091000 by csw900 in GrandOrgue discussion forum on SourceForge

I note that my search for the meaning of sysexraw brought up an unanswered "arduino" query and your unanswered query above in the the search results but nothing else. I have never heard of sysexraw and I am pretty certain that GO cannot produce these message events.

GO can produce an output of the stops that are being used but only as NRPN's. You can convert this output into text with a bit of software but it would be valid only for the organ it was designed for. If you can convert sysexraw messages into a text for display on an OLED screen then using the NRPN's should be a piece of cake.

csw900

[larspalo]

Originally posted 2021-07-21 10:19:55.174000 by gtc131 in GrandOrgue discussion forum on SourceForge

Thanks for the reply.

My understanding us that MIDI SYStem EXclusive messages contain strings of characters (i.e. raw data) which need to be unpacked/interpreted by the MIDI device, such as an Arduino.

I am aware of a very useful organ stop dynamic label product newly designed for Hauptwerk which is based on sysex messages containing Stop Labels. I asked the developer if it could be used with GO, and the answer was that if GO can output stop labels via sysex messages then it's likely that it can be used with GO. Hence my question.

The developer has since told me that he believes GO does have sysex message capability and he will try to find time to test his product with GO to see if it works "out of the box" with no need for code changes on his part.

I'm standing by for news on that.

[larspalo]

Originally posted 2021-07-21 12:56:32.832000 by csw900 in GrandOrgue discussion forum on SourceForge

I suspect you are talking about "Active Labels" which are supported both by HW and GO. These have to be set up prior to use and can send selected sysex data to a compatible LCD panel. However you will be disappointed to learn that the LCD dislplays supported have a maximum capacity of 32 characters. Recent versions of HW MAY support more characters (you will have to investigate this yourself) but even if so, GO has not been updated to follow.

csw900

[larspalo]

Originally posted 2021-07-21 13:02:54.863000 by gtc131 in GrandOrgue discussion forum on SourceForge

32 characters is plenty for the majority of commonly encountered stop names.

[larspalo]

Originally posted 2021-07-24 14:17:18.242000 by csw900 in GrandOrgue discussion forum on SourceForge

The problem is that the stops do not appear to have active labels. So as far as I can tell there is no way for GO to send stop name text. It looks as if it was intended to work but was never implemented.

csw900

[larspalo]

Originally posted 2021-07-24 14:28:38.029000 by gtc131 in GrandOrgue discussion forum on SourceForge

> It looks as if it was intended to work but was never implemented.

On that point, it would be nice if one of the GO software experts/developers on here would join this discussion.

[larspalo]

Originally posted 2021-07-25 05:51:45.669000 by Oleg Samarin in GrandOrgue discussion forum on SourceForge

When should GO send the stop names? When some organ is loaded? Or when the player switches stops on/off?

[larspalo]

Originally posted 2021-07-25 07:51:11.575000 by gtc131 in GrandOrgue discussion forum on SourceForge

When the organ is loaded is what I'm seeking, so that dynamic organ labels (via OLED displays) can be used.

I'm not fussed about on/off as the stops are implemented by buttons illuminated by LEDs inside them, and the LEDs are switched on and off when the Arduino controller senses that the stop button is pressed.

As csw900 has said, keeping in step with HW's way of doing it would be highly recommended for compatibility.

[larspalo]

Originally posted 2021-07-25 06:31:32.699000 by csw900 in GrandOrgue discussion forum on SourceForge

In order to be useful it should send the stop names when an organ is loaded. There is no need for a name to be sent again when a stop is opened or closed but it would be useful if a signal was also sent to indicate the open/closed status.

It would be useful to copy the format of the appropriate HW sysex events otherwise nobody will be able to use them.

I am thinking of making eplayOrgan do this as it is very easy to do. However it will generate a lot of extra midi traffic and most users do not need it. A touch screen is the easiest way to set stops.

csw900

[larspalo]

Originally posted 2021-07-25 07:50:02.570000 by Mark Bugeja in GrandOrgue discussion forum on SourceForge

"In order to be useful it should send the stop names when an organ is
loaded. There is no need for a name to be sent again when a stop is
opened or closed but it would be useful if a signal was also sent to
indicate the open/closed status."

The stop names should be coded as /labels/ and come on when organ is
loaded... status of corresponding /stop /will be determined by current
coding for */stops /*I imagine.

Mark

On 25/07/2021 08:31, csw900 wrote:
>
> In order to be useful it should send the stop names when an organ is
> loaded. There is no need for a name to be sent again when a stop is
> opened or closed but it would be useful if a signal was also sent to
> indicate the open/closed status.
>
> It would be useful to copy the format of the appropriate HW sysex
> events otherwise nobody will be able to use them.
>
> I am thinking of making eplayOrgan do this as it is very easy to do.
> However it will generate a lot of extra midi traffic and most users do
> not need it. A touch screen is the easiest way to set stops.
>
> csw900
>
> ------------------------------------------------------------------------
>
> Can GO output Stop Name text via MIDI SysExRaw messages?
> <https://sourceforge.net/p/ourorgan/discussion/962124/thread/b246e223b8/?limit=25#9618>
>
> ------------------------------------------------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/ourorgan/discussion/962124/
> <https://sourceforge.net/p/ourorgan/discussion/962124/>
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
> <https://sourceforge.net/auth/subscriptions/>
>

Attachments in original post:
https://sourceforge.net/p/ourorgan/discussion/962124/thread/b246e223b8/9618/f237/attachment/alternate

[larspalo]

Originally posted 2021-07-25 07:57:25.236000 by Oleg Samarin in GrandOrgue discussion forum on SourceForge

If HW supports it, could someone capture it's midi out into a file and post it there as example?

[larspalo]

Originally posted 2021-07-25 08:00:46.606000 by Oleg Samarin in GrandOrgue discussion forum on SourceForge

> In order to be useful it should send the stop names when an organ is loaded.

But organs usually have dosens of stops, so their names together would'n fit to 32-char limits.

Or it should send the name of each stop to a separate midi device?

[larspalo]

Originally posted 2021-07-25 08:27:05.053000 by gtc131 in GrandOrgue discussion forum on SourceForge

As I mentioned earlier in this thread, the names of individual stops commonly found will each easily fit into 32 characters.

Here is a product which I am very interested in using for GO. The author has told me that he is happy to accommodate GO as long as he does not have to modify his Arduino code which was developed for HW.

http://www.kaspencer.com/project2.htm

[larspalo]

Originally posted 2021-07-25 12:04:45.502000 by Oleg Samarin in GrandOrgue discussion forum on SourceForge

So it is necessary not only to send stops name but also the enable/disable events.

Is there any software emulator of this device for testing?

[larspalo]

Originally posted 2021-07-25 13:18:49.509000 by gtc131 in GrandOrgue discussion forum on SourceForge

> So it is necessary not only to send stops name but also the enable/disable events.

If the intention is to follow HW's way of operating, then that may be what is required. I'm not au fait with how HW operates at that level but I guess a search of HW technical documentation would provide the answer.

> Is there any software emulator of this device for testing?

I suggest contacting Kenneth Spencer directly about that. (kas at kaspencer dot com)