Pedro López-Cabanillas

I wanted to use the "midi.autoconnect" setting in Windows today, and was disappointed. Then, while looking at #677 it seemed to be easy to implement it in winmidi, but there...

> Sry, it's not quite clear to me what you're asking for or trying to achieve. You are right. I've not made a proposal yet. But I have something in...

> > then if "midi.autoconnect" is requested, instead of parsing the value of "midi.winmidi.device", > > Why not parsing winmidi.device? If the user takes the effort to set it, it...

> 1)The synth.midi-channels winmidi independence of #677 was an important design choice. The synthesizer instance (the object that transforms MIDI events into audio) has only 16 MIDI channels by default....

> 2)with #677, having more than one MIDI controller and one synth instance with only 16 MIDI channels is still a valid use case. This is because any fluid MIDI...

> I understand what you explained so far Pedro, but having a magic MIDI channel mapping (modulo "synth.midi-channels") incorporated inside the MIDI driver could produce MIDI channels conflicts. Your proposal...

This issue is about **extend implementation of "midi.autoconnect"**

This is in my opinion an entirely valid issue. Fluidsynth is not functional without a Soundfont. And there are messages complaining about a missing 'default.sf2' when another soundfont file is...

> Thanks for bringing this up. > > 1. I don't see too much benefit in moving to the new project() syntax. It is only a cosmetic thing for now,...

> I have to admit it's hard for me to comprehend your different views / use-cases and understand the differences. Which makes it hard to make a decission here. AFAIU,...