Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output to real hardware #25

Open
tevey opened this issue Nov 3, 2023 · 7 comments
Open

Output to real hardware #25

tevey opened this issue Nov 3, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@tevey
Copy link

tevey commented Nov 3, 2023

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
Copy link
Owner

stuerp commented Nov 3, 2023

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
Copy link

d-bind commented Nov 13, 2023

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
Copy link
Owner

stuerp commented Nov 13, 2023

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?

@stuerp stuerp added bug Something isn't working enhancement New feature or request and removed bug Something isn't working labels Nov 13, 2023
@d-bind
Copy link

d-bind commented Nov 13, 2023

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
Copy link
Owner

stuerp commented Nov 13, 2023

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
Copy link
Owner

stuerp commented Dec 23, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants