Internal MIDI Interface?

Question

Internal MIDI Interface?

notator opened this issue 9 years ago · comments

Would it be possible to separate this project's GUI (Graphic User Interface) from its synth code, using an interface like the one I describe at [1]?

I have my own GUI, and would just like to use the synth. :-)

My proposed interface is, of course, just a sketch. Maybe you have other ideas about how to do this?

Very best wishes,
James

[1] WebAudio/web-midi-api#154

James Ingram · Answer 1 · Sat Oct 17 2015 22:09:12 GMT+0800 (China Standard Time)

I have now downloaded this project, and am going to see if I can isolate the SoundFont synth myself.
Will let you know here how I get on. :-)

Phillip · Answer 2 · Sun Oct 18 2015 02:35:42 GMT+0800 (China Standard Time)

I'll be watching any updates and will post findings if I make progress when I get to work on it. As noted in the issue I raised, it would be of value to know if the synth can be used without https. The app source posted by Ryoya on that issue may perhaps be useful for that purpose

Ryoya KAWAI · Answer 3 · Mon Oct 19 2015 11:46:39 GMT+0800 (China Standard Time)

Sorry for late reply.
Well, have you seen these?
[w/ x-webmidi]
[w/o x-webmidi]

I can not have confident that I am answering your question correctly, but I think this would be the isolated style.

James Ingram · Answer 4 · Mon Oct 19 2015 16:55:38 GMT+0800 (China Standard Time)

I'm afraid the links don't help much. The coding level is too high! :-)
Here's a progress report. Hope it helps you understand better what I'm trying to do:

I've been digging about in your smfplayer code, and see that you are using logue's code from
http://logue.github.io/smfplayer.js/wml.html
This code includes a GUI that I still need to remove to get at the basic synth.

I want to create a GitHub repository whose purpose is to define an interface for software SoundFont synthesizers, and I want to use the logue synth code in the first implementation of that interface. Using a concrete example should help me develop the interface, and at the same time provide a working synth that can easily be included on any website.

I'm hoping that:

having a well defined interface will encourage Web Audio programmers to write new synth code. (For example, as far as I can see, the logue synth does not support continuous controllers.)
my new repo will provide some useful background info for the WebMIDIAPI working group when they get to their v2.

Ryoya KAWAI · Answer 5 · Mon Oct 19 2015 18:44:09 GMT+0800 (China Standard Time)

I'm afraid the links don't help much. The coding level is too high! :-)

Sorry that I did not explain in detail.
wm-webmidilink has attribute like below.

<wm-webmidilink targetsynth="[URL]" width="[width]" height="[height]" linklevel="[0 or 1]"></wm-webmidilink>

targetsynth is for specify the synth's URL that created in Web Audio API.
width/height is for the width/height of the synth that is specified in targetsynth.
linklevel is the LinkLevel of Web MIDI Link which specified here.

So what the developer must do to use virtual Web Audio Synth with wm-webmidilink is following:

import Polymer itself.
import wm-webmidilink element
add wm-webmidilink tag with specifying targetsynth, width/heigth and linklevel
get object from wm-webmidilink by .getInput() method and add it to MIDI output list.

And what those who wants to develop virtual Web Audio Synth need to do is simply to support Web Midi Link.

For example:
This markup loads soundfont synth.

<wm-webmidilink targetsynth="http://logue.github.io/smfplayer.js/wml.html"></wm-webmidilink>

Web Components(Polymer) is a part of the "Extensible Web", so it would be the standard way to extend Web API in near future. And if these steps are still difficult for the developer, I guess Web Audio/MIDI API is also difficult for that developer.

James Ingram · Answer 6 · Mon Oct 19 2015 19:22:37 GMT+0800 (China Standard Time)

The problem there is that I really need to get rid of the synth's GUI. Parameters like width and height are referring to something inessential, that has to be removed.
I think it is going to be much easier for Web Audio developers to write synth code when they can program to an interface that does not include GUI parameters. Synths then become just ordinary Web Audio code.

I'm currently writing a minimal host (GUI) for the (GUI-less) logue synth. Maybe I'm going to fail with egg all over my face, but I currently don't think that's going to happen. Lets wait and see...

Ryoya KAWAI · Answer 7 · Mon Oct 19 2015 23:22:47 GMT+0800 (China Standard Time)

I am looking forward to see your GUI-less synth.

But.... my understanding is right, are you saying that Web Audio virtual synth without GUI is much easier to write for developer? Yes, I agree that. However, how can users, who are using web site that has Web Audio virtual synth, know what is happening with Web Audio virtual synth during playing? And how can users change the parameters of Web Audio virtual synth?
In VST's case, I think most of those instruments have some GUI to control parameters and/or to monitor VST activities.

And <wm-webmidilink> element uses on the application that embed external Web Audio virtual synth, not on the Web Audio virtual synth application page. So adding width/height or NOT adding width/height is the choice of the application that embed external Web Audio virtual synth.

By the way, I added nogui attribute to <wm-webmidilink> element. When you added the attribute, GUI does not dispay if you click MIDI icon next to select list.
(App)
(Code)

James Ingram · Answer 8 · Mon Oct 19 2015 23:47:52 GMT+0800 (China Standard Time)

how can users, who are using web site that has Web Audio virtual synth, know what is happening with Web Audio virtual synth during playing?

The synth is loaded into a host app that provides the GUI.

And how can users change the parameters of Web Audio virtual synth?

Using the host application's GUI. The host interacts with the synth via the internal interface. Its up to the host to decide what users can and cannot do. Its really very simple. :-)

Ryoya KAWAI · Answer 9 · Tue Oct 20 2015 10:04:07 GMT+0800 (China Standard Time)

OK, now I may understand what you are trying to do. You are trying to define only interface between host app and the web audio synth. It sounds something new. So the point of your proposal is to separate GUI and sound algorithm, and let host app developer to implement their original GUI with that sound algorithm.

So the between yours and wm-webmidilink has totally upset idea. The idea of wm-webmidilink is that let developers to use web audio synth by only setting url in its attribute.

James Ingram · Answer 10 · Tue Oct 20 2015 17:38:04 GMT+0800 (China Standard Time)

Yes, that's right.
I'm a bit busy with other things today, but should have something presentable by the beginning of next week. Will keep you posted, of course.

James Ingram · Answer 11 · Sat Oct 24 2015 02:22:58 GMT+0800 (China Standard Time)

Thanks Ryoya! In #2, you said:

...my recommendation would be fork sf2synth.js and modify it by yourself and use it as same as sf2synth.js is doing to play SMF.

That's exactly what I'm going to do. Your recommendation comes at exactly the right moment.
I began looking seriously at the synth code this morning, after completing my GUI (without the synth, but with a well defined synth interface). Was running into trouble because the version in your smfplayer is minified.
At a first glance, it looks as if the original sf2synth.js code includes more functionality than you actually used in WebMIDILink. Very curious to see where this ends up!

Sorry I'm running a couple of days later than announced. Will definitely publish something during the coming week.

James Ingram · Answer 12 · Wed Nov 11 2015 02:32:53 GMT+0800 (China Standard Time)

Hi Ryoya,
see WebAudio/web-midi-api#124
Have fun! :-)