Midi Player + VMS

Please let our ADS show!

This sites offers only FREE software and it's supported by a few advertisement boxes (no intrusive popups).
Please:

  • disable your AdBlocker by adding CoolSoft website to whitelist
  • give the proper cookie consent
  • enable JavaScript for this website

This seconds wait is to let you update your browser configuration...

Ok, I've done the required changes... now show me your content!
!!! Please enable JavaScript !!!

Pagine

Posts: 129
Joined: 25 Set 2013 - 16:38
Re: SysEx messages

When I wrote (5 years ago :) ) that encoding arbitrary paths in SysEx is not an easy task I also thought about localized/Unicode strings.

Even modern Windows still supports single byte localized ANSI strings (bytes above the fixed ASCII values are interpreted according to the system locale set in Windows).

But there is a problem. Although it's true that SysEx is a free format as Rimokatolik has written but there are restrictions.

Bytes F0 (SOX) and F7 (EOX) have special meaning and also data bytes (basically anything between F0 and F7) are restricted to the range of 0 - 7F.  So neither localized ANSI nor Unicode strings can be directly/freely encoded as data bytes.

Even if VMS could overcome this restriction the Midi infrastructure of Windows/Midi software cables etc. could not transmit invalid SysEx messages. A solution could be to first base64 encode the ANSI/Unicode string and then the base64 encoded data should be sent as data bytes in the SysEx messages.

But I seriously do not think that this would be a convenient and popular soulution.

Posts: 8
Joined: 2 Giu 2018 - 06:58
Re: SysEx messages

Even though it is true that unicode is default in many cases, and localized ANSI strings are still supported, ASCII is still the main common denominator. I don't remember seeing download files that are outside of basic chars in ASCII (lower 127 chars, basically English wih some special chars like underscore). Still, even if file paths are not supported it would still be OK, as I could preload all fonts in VMS and not activate them on any channel, just have them available to activate using sysex. You still have an issue of sending text in sysex, as the only way to differentiate them is by name, so we are back to why not support paths too if names have to be supported anyway.

I don't understand what old players have to do with this new feature? Whoever wants to use it needs to write new code.

Posts: 129
Joined: 25 Set 2013 - 16:38
Re: SysEx messages

Hi,

Rimokatolik wrote:
Even though it is true that unicode is default in many cases, and localized ANSI strings are still supported, ASCII is still the main common denominator. I don't remember seeing download files that are outside of basic chars in ASCII

I intentionally have not spoken about soundfont file names but paths. While it's true that downloaded files usually do not contain localized strings, the moment you saved it on your desktop the path itself can contain localized characters. And usually really contains if you are not an English man/your language does not use latin alphabet. It's because desktop/documents/downloads etc. folders that are freely usable on modern Windows by all users without elevation contain the user's name.  So even if the user is not aware of it explicitly, localized strings can be an issue. An example from my experience:

https://www.vogons.org/viewtopic.php?f=24&t=48207&hilit=greek&start=520#p611015

Rimokatolik wrote:
You still have an issue of sending text in sysex, as the only way to differentiate them is by name, so we are back to why not support paths too if names have to be supported anyway.

Not necasarily, if the SySex is referring to a preconfigured soundfont in VMS's known soundfont list. Then it can have an ID number that can be encoded in the SysEx easily.

Rimokatolik wrote:
I don't understand what old players have to do with this new feature? Whoever wants to use it needs to write new code.

Also not necessarily. If you use the above suggested ID based reference no new code should be written, all old software could use the new feature. The only requirement would be that the software support normal SysEx sending (even Claudio's old favorite player Van Basco supports it). My midi player already supports same named mid+syx file pairs so the content of the syx file is sent before the midi file is played. This way every midi file could activate/preload the required soundfont before playing the midi file. No new code is necessary.

Posts: 8
Joined: 2 Giu 2018 - 06:58
Re: SysEx messages

I understand your point regarding users' paths, but for me in order of sysex suport to be useful I need to receive text, not only name of sound font, but also presets it contains (that you can easily get in VMS' UI now). Otherwise, I need to do what I am doing now and save names in my database. ID itself does not help much. I understand it would enable some work on sounds fonts configuration, but I would still need to do prep work, as oppose getting all info in runtime.

Either way I can live with it, I am living now without sysex support at all in VMS :-)

Posts: 129
Joined: 25 Set 2013 - 16:38
Re: SysEx messages

Wait a minute. We are talking about 2 completely different things. This topic (that you revived after 5 years ) is explicitly about ways to configure VMS soundfont stack remotely. In this context sending complete soundfont paths does not seem to be practical.

But you are talking about RECEIVING info about VMS existing soundfont configuration. These 2 must be 2 different SysEx commands regardless of full soundfont path support. In your case localization is not a serious problem since SF2 format itself is rather restricted e.g. about preset name's length/encoding. So preset names are very much likely do not contain localized strings.

So you should make another whislist topic since your issue is completely different from the one this topic is about.

Ps:

If your software can/will support VST instrument plugins you are in a much better position since in VST world there is a standars mechanism to get instrument names. I have a Bassmidi VSTi plugin that uses the same Bass/Bassmidi libraries as VMS so it sounds identical to VMS but supports midiProgramNames() call to send you the name of each preset in all banks.

Posts: 1972
Joined: 25 Mar 2012 - 01:19
Re: SysEx messages
falcosoft wrote:
But you are talking about RECEIVING info about VMS existing soundfont configuration.

There's no way for VMS (or any other MIDI out device) to reply to a received SysEx.
MIDI events flow one way from MIDI client ---> VMS, no way (I know) to return any kind of answer.

Rimokatolik wrote:
I don't understand what old players have to do with this new feature? Whoever wants to use it needs to write new code.

I'd like my users to be able to change soundfonts (or maybe change anything in VMS configuration) also from their "hardware" MIDI Keyboard, by programming the required SysEx on the keyboard display.
Entering a full filename there won't be an easy task ;)

Pagine