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!Pages
- falcosoft
- Posts: 129
- Joined: September 25, 2013 - 16:38
- Rimokatolik
- Posts: 8
- Joined: June 2, 2018 - 06:58
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.
- falcosoft
- Posts: 129
- Joined: September 25, 2013 - 16:38
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.
- Rimokatolik
- Posts: 8
- Joined: June 2, 2018 - 06:58
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 :-)
- falcosoft
- Posts: 129
- Joined: September 25, 2013 - 16:38
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.
- coolsoft
- Posts: 1978
- Joined: March 25, 2012 - 01:19
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 ;)
Pages
Navigation
Login
Support me
Click here if you want to support CoolSoft using PayPal