search

stuerp / foo_midi

A foobar2000 component to play MIDI files.
MIT License
58 stars 1 forks source link

Output to real hardware #25

Open tevey opened 10 months ago

tevey commented 10 months ago

Hi, I have a roland sc-55 connected to my computer with a usb to midi cable, is there any way i can configure this plugin to output to the sc-55?

stuerp commented 10 months ago

Short version: No

Longer version: While foo_midi works like a sequencer by sending messages to a 'device', it does except the 'device' to respond with a rendered version of the messages in the form of sound samples. Your hardware device will render directly to the audio subsystem of Windows. foo_midi has nothing to pass on to foobar2000 to play.

d-bind commented 10 months ago

I'm aware of some previous discussions on this, but now that the development has changed hands, maybe you'd consider the "passthru" approach? Feed silence to foobar while sending midi commands to the system device.

If you're concerned that some features won't work as expected by the user (conversion, volume control, etc), just toggle this off by default and put the checkbox into advanced settings, with a big fat warning.

stuerp commented 10 months ago

I'm aware of some previous discussions on this, but now that the development has changed hands, maybe you'd consider the "passthru" approach? Feed silence to foobar while sending midi commands to the system device.

I'll read the discussion later but the question remains: why use an audio player instead of a dedicated sequencer application? And how would I test that?

d-bind commented 10 months ago

Well the "system device" in question would be the Microsoft GS SoftSynth by default (on Windows). Since the build instructions are for Visual Studio, I assume you'd be able to test this quite easily.

The conservative implementation would be just that, passing midi events to the system's default midi out. Further routing of events to a physical external module could be left to the user (using Midi Mapper, for example).

The "why" is simple convenience - keeping playlists / tags / cover art within foobar, rather than using another player for one specific output option of one specific format. Maybe I don't understand the question.

Edit: I guess I'll clarify that I didn't mean any extra receiving capability by "passthru". I just meant that you'd be playing a midi file as it is right now, but sending the events off to the system (blindly), and feeding foobar silence to keep seekbar etc working.

stuerp commented 10 months ago

Well the "system device" in question would be the Microsoft GS SoftSynth by default (on Windows). Since the build instructions are for Visual Studio, I assume you'd be able to test this quite easily.

I'm intrigued, maybe later. But first I want to get to a stable version of foo_vis_spectrum_analyzer.

stuerp commented 8 months ago

I started implementing this feature but I ran into a design problem: currently players get fed MIDI events in bursts based on the duration of an audio chunk (typically about 10ms worth). The timestamps of the events have been converted to sample offsets during pre-processing because the 'clock' is based on sample buffer requests. Feeding this stream type to the SoftSynth using midiOutShortMsg() works but there are a lot of hick-ups in the playback because the call takes a while to return and seems to miss events that are sent too fast. The alternative is to use the MIDI stream buffer API but that requires the delta timestamps to be intact. It's going to take a lot (too much?) of rework to shoehorn this feature in the current design.

JWatersMeet commented 5 months ago

For what it's worth, I tried to implement something similar for a hardware YMF262 over a serial link, and ran into the same issue.