-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
Short version: No Longer version: |
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. |
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? |
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. |
I'm intrigued, maybe later. But first I want to get to a stable version of foo_vis_spectrum_analyzer. |
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. |
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. |
At this time, pass-through to MIDI devices can still be achieved by using falcosoft's WinMM MultiPort Vsti Plugin. This plug-in is a VSTi but does not generate sound. However, it also does not play well, probably for the reason of #25 (comment) |
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?
The text was updated successfully, but these errors were encountered: