Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
2010-08-08 23:42, Pedro Lopez-Cabanillas skrev: >> How about we release 1.1.2 now, list this as a known issue, and release >> 1.1.3 as soon as this is agreed, fixed and finished, with Sysexes, >> settings, and so on? >> If that then takes just a week - then we can release 1.1.3 just a week >> after 1.1.2. What do you think about that? > > I don't agree with releasing 1.1.2 with this bug. If we need to delay the > release date one, or two, or three weeks, it should be delayed. Why are you > in a hurry? 1. Current trunk has some quite important reordering issues fixed with my big thread safety rewrite, which should reach the users ASAP. In short, current trunk is better, has more testing and is more stable than 1.1.1, which is why we should release. 2. If this was a critical bug to many users, it would have shown up much earlier than half-a-year after 1.1.0/1.1.1 was released, so overall, it is not critical enough to delay a release. 3. There is a risc that, if we wait a few weeks to get this in, a new bug might show up which will make us want to fix that one in a few weeks, and so on, it'll be an infinite (or at least long running) loop of fixing and testing. I've seen it happen before, and I believe it's about to happen again. 4. This new feature (recognizing sysex in particular), requires changes to many of the MIDI drivers, and we risc regressions. I doubt that we'll make it even in three weeks, with all the testing required. 5. For more arguments, see the chapter "release early, release often" in "The cathedral and the bazaar" by Eric S Raymond (available online, in many copies). // David ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
2010-08-08 23:42, Pedro Lopez-Cabanillas skrev: > On Sunday, August 8, 2010, David Henningsson wrote: > SF2 (SoundFont) files (like GeneralUser, FluidR3,...) have bank numbers > < 127 for melodic sounds and 128 for Drum kits, as recommended by the > SoundFont specification [5]. It is necessary to map the MIDI Bank > Select numbers to the SF2 bank numbers, because they won't always > match. The sf2 spec says that "The special case of a General MIDI > percussion bank is handled conventionally by a wBank value of 128. If > the value in either field is not a valid MIDI value of zero through > 127, or 128 for wBank, the preset cannot be played but should be > maintained." >>> >>> I want to remark the above quotation from the SF2 specification. SF2 bank >>> numbers for melodic channels are numbers in the range 0 to 127, 7 bits. >> >> 128 for wBank. I saw nothing about that in your proposal, or if the drum >> MIDI channel should be handled in another way than the rest of the >> channels, could you elaborate on that? > > Melodic channels means all channels except the drum channel. Channel#10 is > the > MIDI drum channel number reserved in the GM specification, and all the other > extensions. This is not true according to http://en.wikipedia.org/wiki/Comparison_of_MIDI_standards - neither GS, XG and GM2 specify channel #10 as the one and only drum channel. > SF2 Bank 128 is only intended to be applied on the MIDI drum > channel, not on melodic channels. It is well explained in the SF2 > specification and appendix documents. I'm not sure I understand you correctly. Is your proposal that we ignore CC0 and CC32 for channel #10 and hard-code it to 128? // David ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
On Monday, August 9, 2010, David Henningsson wrote: > 2010-08-08 23:42, Pedro Lopez-Cabanillas skrev: > >> How about we release 1.1.2 now, list this as a known issue, and release > >> 1.1.3 as soon as this is agreed, fixed and finished, with Sysexes, > >> settings, and so on? > >> If that then takes just a week - then we can release 1.1.3 just a week > >> after 1.1.2. What do you think about that? > > > > I don't agree with releasing 1.1.2 with this bug. If we need to delay the > > release date one, or two, or three weeks, it should be delayed. Why are > > you in a hurry? > > 1. Current trunk has some quite important reordering issues fixed with > my big thread safety rewrite, which should reach the users ASAP. In > short, current trunk is better, has more testing and is more stable than > 1.1.1, which is why we should release. Your interests are very important for you, and the interests of other people are secondary. I'm not the only one that is now advocating for resolving this problem, but if it remains unfixed in FS-1.1.2 it will be probably seen as your own fault, and you are not interested in giving this perception, right? You have done a great work in this release, congratulations for that! Why do you want to let such an ugly spot over your work? > 2. If this was a critical bug to many users, it would have shown up much > earlier than half-a-year after 1.1.0/1.1.1 was released, so overall, it > is not critical enough to delay a release. Instead of creating a new ticket, I chose to use the subject "Son of ticket #65" because until you fixed the problem of the queued messages processing order, this issue was masked and hidden behind the more general effects of ticket #65. Now, this loose end becomes more prevalent, and must be fixed as well. > 3. There is a risc that, if we wait a few weeks to get this in, a new > bug might show up which will make us want to fix that one in a few > weeks, and so on, it'll be an infinite (or at least long running) loop > of fixing and testing. I've seen it happen before, and I believe it's > about to happen again. > > 4. This new feature (recognizing sysex in particular), requires changes > to many of the MIDI drivers, and we risc regressions. I doubt that we'll > make it even in three weeks, with all the testing required. I've offered myself to work and try to fix this issue, if there is enough consensus about a proposal. Right now, it is your opposition what is blocking me to do anything. Regards, Pedro ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
On Monday, August 9, 2010, David Henningsson wrote: > 2010-08-08 23:42, Pedro Lopez-Cabanillas skrev: > > On Sunday, August 8, 2010, David Henningsson wrote: > > SF2 (SoundFont) files (like GeneralUser, FluidR3,...) have bank > > numbers < 127 for melodic sounds and 128 for Drum kits, as > > recommended by the SoundFont specification [5]. It is necessary to > > map the MIDI Bank Select numbers to the SF2 bank numbers, because > > they won't always match. The sf2 spec says that "The special case of > > a General MIDI percussion bank is handled conventionally by a wBank > > value of 128. If the value in either field is not a valid MIDI value > > of zero through 127, or 128 for wBank, the preset cannot be played > > but should be maintained." > >>> > >>> I want to remark the above quotation from the SF2 specification. SF2 > >>> bank numbers for melodic channels are numbers in the range 0 to 127, 7 > >>> bits. > >> > >> 128 for wBank. I saw nothing about that in your proposal, or if the drum > >> MIDI channel should be handled in another way than the rest of the > >> channels, could you elaborate on that? > > > > Melodic channels means all channels except the drum channel. Channel#10 > > is the MIDI drum channel number reserved in the GM specification, and all > > the other extensions. > > This is not true according to > http://en.wikipedia.org/wiki/Comparison_of_MIDI_standards - neither GS, > XG and GM2 specify channel #10 as the one and only drum channel. You are manipulating my words. I've never said "the one and only". The channel #10 is the drum channel in GM level 1 standard, and this setting (as a default or recommendation) has been inherited by all the other GM extensions. GS defaults to channel #10 as the drum channel. The drums may be assigned to another channel using a SYX message. XG defaults and recommends channel #10 as the drum channel. Other channels may be used as drum channels when CC#32=127 is received on any channel. I'm not proposing to implement every GS, XG and GM2 feature at this time. There are many things to take into account to properly emulate all those standards. This can be implemented step by step in future releases. What I'm proposing is to fix *NOW* the broken behavior that is plaguing FluidSynth-1.1.x converting any melodic channel into a drum channel when a CC#32=1 is received in a channel. This behavior doesn't correspond to any standard. It is utterly wrong. > > SF2 Bank 128 is only intended to be applied on the MIDI drum > > channel, not on melodic channels. It is well explained in the SF2 > > specification and appendix documents. > > I'm not sure I understand you correctly. Is your proposal that we ignore > CC0 and CC32 for channel #10 and hard-code it to 128? What I am proposing is to follow the SF2 standard, and assign the SF2 bank 128 only to drum channels. And currently, only channel #10 can be a drum channel. For the future, the "drum enabled" property would be a boolean setting, belonging to the channel state. My proposal for future developments is to add a new "is_drum" field to the fluid_channel_t structure [fluid_chan.h], and initialize it to true for channel #10 in fluid_channel_init() [fluid_chan.c] and to false for any other channels. In the future, this field could be changed with a new setter function, allowing the extra drum channels features in GS, XG and other modes, when those modes become implemented in full. Regards, Pedro ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
On Monday, August 9, 2010, I wrote: > XG defaults and recommends channel #10 as the drum channel. Other channels > may be used as drum channels when CC#32=127 is received on any channel. > > What I'm proposing is to fix *NOW* the broken behavior that is plaguing > FluidSynth-1.1.x converting any melodic channel into a drum channel when a > CC#32=1 is received in a channel. This behavior doesn't correspond to any > standard. It is utterly wrong. It is CC#0 instead of CC#32 in both sentences. The correct information is: XG defaults and recommends channel #10 as the drum channel. Other channels may be used as drum channels when CC#0=127 is received on any channel. What I'm proposing is to fix *NOW* the broken behavior that is plaguing FluidSynth-1.1.x converting any melodic channel into a drum channel when a CC#0=1 is received in a channel. This behavior doesn't correspond to any standard. It is utterly wrong. Sorry, my mistake. Regards, Pedro ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
It seems simple enough to revert the behavior to 1.0.9 functionality. This should work fine in most cases, as far as the whole MSB is actually LSB when only the MSB is received. I can understand David wanting to release ASAP, since he has been waiting for a while to do so. But I think the behavior of the bank switching should be dealt with, since I see it as being pretty trivial to fix and a significant enough of an issue. This doesn't mean implementing the MIDI mode setting at this time. It simply just needs to be reverted to the previous behavior, which means that if only the MSB is received prior to a Program Change, then it should be interpreted as LSB. If both MSB and LSB are received, they should combine to select the bank (once the Program Change is received) as MSB * 128 + LSB. In cases where a MIDI file or device is expecting GS behavior, I don't think it would ever send an LSB message. So this logic should work in all MIDI modes. There were no complaints about this in 1.0.9 and previous. Lets put off the MIDI mode switching logic, SYSEX interpretation, etc. The code has already been implemented and could be taken from SVN history, but it would need to be integrated with the new code base, tested, etc. How does that sound? Elimar ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] FluidSynth 1.1.2 release notes
On Sun, Aug 8, 2010 at 1:05 AM, David Henningsson wrote: > I started drafting on 1.1.2's changelog here: > > https://sourceforge.net/apps/trac/fluidsynth/wiki/ChangeLog1_1_2 > > Big changes: > > * New CMake build system [plcl] > * Winbuild directory dropped, autotools deprecated but still > working > * Rewriting of thread safety [diwic] > * Describe the two new settings here > > Smaller changes: > > * Voice overflow settings [diwic] > * Possible to update polyphony, up to 65536 (beyond initial setting) > [diwic] > * Sample rate is updatable (and jack driver updates sample rate > correctly) [diwic] > * To be committed: Change of bank number handling [plcl] > * Source files moved into different subdirectories [diwic] > * Can use RealTimeKit (on Linux) to get real-time priority [diwic] > * Shell commands for pitch bend and pitch bend range [monk] > * PulseAudio driver: specify media role, and allow pulseaudio to > adjust latency [diwic] > * Bug fixes [diwic, plcl, KO Myung hun, Felix Krause, laurent] > > Anything missing in the above list, or incorrectly attributed? > > I've also updated the autotools build, so it should be working now. So > are we currently just waiting for the banknum stuff to be agreed upon > and implemented before releasing 1.1.2? > > // David > Looks great! As far as I know, its just the bank switching issue that remains. Lets deal with that one. I was starting to look over the code changes you made. It looks like a pretty extensive overhaul to me and I still don't quite have a whole picture of how you have implemented things. Does it seem to have similar performance as previous versions? I'll review your changes some more, to see if I can catch any potential thread related bugs or what have you, though I'm sure its perfect ;-) I may have some questions for you though, to try and get a better idea of how you have done things. Cheers! Elimar ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
On Tuesday, August 10, 2010, Elimar Green wrote: > It seems simple enough to revert the behavior to 1.0.9 functionality. > This should work fine in most cases, as far as the whole MSB is > actually LSB when only the MSB is received. > > I can understand David wanting to release ASAP, since he has been > waiting for a while to do so. But I think the behavior of the bank > switching should be dealt with, since I see it as being pretty trivial > to fix and a significant enough of an issue. This doesn't mean > implementing the MIDI mode setting at this time. It simply just needs > to be reverted to the previous behavior, which means that if only the > MSB is received prior to a Program Change, then it should be > interpreted as LSB. If both MSB and LSB are received, they should > combine to select the bank (once the Program Change is received) as > MSB * 128 + LSB. In cases where a MIDI file or device is expecting GS > behavior, I don't think it would ever send an LSB message. So this > logic should work in all MIDI modes. There were no complaints about > this in 1.0.9 and previous. > > Lets put off the MIDI mode switching logic, SYSEX interpretation, etc. > The code has already been implemented and could be taken from SVN > history, but it would need to be integrated with the new code base, > tested, etc. > > How does that sound? > > Elimar I agree that we can leave the SYSEX stuff for a future release, avoiding the risk of spend too much time implementing and testing this feature. In addition to your code, I've included similar functionality in kmidimon. I disagree with simply reverting to 1.0.9, because adding a new setting "midi.bank-select" with several options is easy enough, and may be needed for accurate playback of different songs. In my opinion, the default should be the awe32 mode, as recommended by the appendix 1 of the SF2 standard. Regards, Pedro ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
2010-08-10 08:01, Pedro Lopez-Cabanillas skrev: > On Tuesday, August 10, 2010, Elimar Green wrote: >> It seems simple enough to revert the behavior to 1.0.9 functionality. >> This should work fine in most cases, as far as the whole MSB is >> actually LSB when only the MSB is received. >> >> I can understand David wanting to release ASAP, since he has been >> waiting for a while to do so. But I think the behavior of the bank >> switching should be dealt with, since I see it as being pretty trivial >> to fix and a significant enough of an issue. This doesn't mean >> implementing the MIDI mode setting at this time. It simply just needs >> to be reverted to the previous behavior, which means that if only the >> MSB is received prior to a Program Change, then it should be >> interpreted as LSB. If both MSB and LSB are received, they should >> combine to select the bank (once the Program Change is received) as >> MSB * 128 + LSB. In cases where a MIDI file or device is expecting GS >> behavior, I don't think it would ever send an LSB message. So this >> logic should work in all MIDI modes. There were no complaints about >> this in 1.0.9 and previous. >> >> Lets put off the MIDI mode switching logic, SYSEX interpretation, etc. >> The code has already been implemented and could be taken from SVN >> history, but it would need to be integrated with the new code base, >> tested, etc. >> >> How does that sound? >> >> Elimar > > I agree that we can leave the SYSEX stuff for a future release, avoiding the > risk of spend too much time implementing and testing this feature. In > addition to your code, I've included similar functionality in kmidimon. > > I disagree with simply reverting to 1.0.9, because adding a new > setting "midi.bank-select" with several options is easy enough, and may be > needed for accurate playback of different songs. In my opinion, the default > should be the awe32 mode, as recommended by the appendix 1 of the SF2 > standard. Fair enough, go ahead. I would say we skip the "awe32" alias though, I think it causes confusion to have two setting values doing the same thing. // David ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
