Hi, Marcus,
>I was very happy when you posted that patch and I had a good look through it. >My instrument behaves very similar to a breath controller, so it would >probably benefit a great >deal from the functionality your patch adds to >FluidSynth. >When you implemented all the changes for ticket 160, did you maybe make >smaller local commits for the individual features that you could provide as >separate patches? No, because, for the individual features that can be see as functionnaly independant each to other (ie legato and portamento ), at noteOn the decision of triggering a portamento can depend of certains legato mode. So triggering a feature may depend of the triggerring of another feature. I'm sorry. However, the steps order use when coding the features has been the chapters order in the pdf (i.e Part 1 with details given in 2.8 followed by Part 2 with details in 3.11). Theses steps has been choosen to make the coding progression as easy as possible particularly for testing purpose. Following is a small guide to understand the goal of the poly/mono patch (ticket 160) and it can help to read the source patch and the pdf also as it is an attempt to "Top to Down" learning via tutorial exemples approach. 0) If necessary, read MIDI CC messages descriptions (poly, mono, omni on , omni off, legato on/off) in pdf 2.4 or any others MIDI spec. document. 1) To feel very quickly more confident ( before reading the source patch), one must build the "already patched" archive (see 1.1.1 - PatchFluidPolyMono-0003.zip) and try the examples directly (see tutorials examples with commands files (see 2.1 and 3.1)). 2) Reading this short guide (below). 3) Then try to read the patch sources. One can also swap (1) and (2). In all case step (3) must be the last steps. Features short Guide: ------------------------ Section 1), mainly , the poly/mono patch (ticket 160) allows a FluildSynth instance to react polyphonically ( as it is the case without the patch) or monophonically , individually on each MIDI channel. So, as soon a Channel is set in mono state, the main benefict is to have this MIDI channel that sound like a monophonic instrument even if the musician plays on a polyphonic MIDI controler (i.e a MIDI piano keyboard). This enhance seriously the ability to play legato articulations in a maner than is difficult to reach if the channel is in poly mode. To obtain this functionnalty, the patch handle the necessary MIDI CC messages (poly, mono, omni on , omni off, legato on/off) (in fluid_synth_cc) and the concept of Basic Channels. So , to dive easly into the patch it is necessary to understand the MIDI specifications about theses CC (Basic Channels can be ignored at first time). So, in short , any of theses CC set a MIDI channel to mono or poly state . On the next stream of noteOn/noteOff MIDI Messages, the patch will be able to play the notes in a monophic or polyphonic manner (in fluid_synth_noteon(), fluid_synth_noteoff() both using fluid_synth_mono.c). Section 2 - legato mode When a mono channel receives noteOn Messages, and the musician is playing legato, the way how the previous note is cancelled before playing the next one is called "legato mode". This parameter is a specific functionnality brings by the patch and have no relation with any MIDI specifications (as far i know). The patch offers "Legato mode" API (in fluid_synth_polymono.c) and shell commands (in fluid_cmd.c, fluid_synth_polymono.c) . To do the job, On noteOn or noteOff the patch call fluid_synth_mono.c-fluid_synth_noteon_mono_legato(). Section 3 - Breath mode Breath mode allows the musician playing on a MIDI keyboard to contol the dynamic of a note in a manner like if he was playing on an electronic wind instrument (i.e ewi). Like "legato mode" these Breath parameter is a specific functionnality brings by the patch and have no relations with any MIDI specifications nor "legato mode". The patch offers "Breath mode" API (in fluid_synth_polymono.c)) and shell commands (in fluid_cmd.c,fluid_synth_polymono.c) . On noteOn, to do the jobs, the patch set the right 'Breath to initialAttenuation modulator' that substitute to the default 'Velocity to initialAttenuation' modulator (in fluid_synth_alloc_voice()). Section 4 - Portamento mode When on playing consecutive notes portamento allows a fluid sweep. CC Portamento on/off, CC portamento time, CC portamento control (PTC) , are handled (in fluid_synth_cc). The patch offers "Portamento mode" API (in fluid_synth_polymono.c)) and shell commands (in fluid_cmd.c,fluid_synth_polymono.c). Portamento Mode allows potamento in polyphonic or monophonic mode in staccato or legato playing practice. >There is your very detailed PDF that describes your ideas and most of the >changes, of course. But its great detail also has it's downsides, at least for >me: I found it hard to >keep track of everything. As an example, I noticed the >following change in your patch....: The BugFixe you have noticed is the only thing that isn't related to the patch It's a very minor bug that produces enveloppe duration lightly different than the one specified in the soundfont. The duration error isn't not perceptible. >In my opinion, this type of change should really be in a separate patch I agree and i'm sorry to induce somes troubles/confusions. Anyway, if you are interresed by the patch, you must know that i am ready to gives all the necessary informations on a step by step basis. Regards > Message du 02/06/17 11:01 > De : "Marcus Weseloh" > A : "FluidSynth mailing list" > Copie à : > Objet : [fluid-dev] Poly/mono patch - ticket 160 (was: Re: New patch: > polyphonic key pressure (aftertouch)) > > Hi Jean-Jacques, > 2017-05-31 19:08 GMT+02:00 Ceresa Jean-Jacques : > To give an example, this idea has been implemented partialy in a previous patch called "Poly/mono patch" (Ticket 160). > > I was very happy when you posted that patch and I had a good look through it. My instrument behaves very similar to a breath controller, so it would probably benefit a great deal from the functionality your patch adds to FluidSynth. > But I must admit that I found it quite hard to review and understand the patch. Mainly because it is so large and adds and changes so many separate parts of the codebase simultaneously: new shell commands, legato functionality, instrument zones, breath mode, maybe more? Also the fact that your patch adds yet another coding style to the codebase made me shy away from it at first (but that is only a minor concern and easily fixed). When you implemented all the changes for ticket 160, did you maybe make smaller local commits for the individual features that you could provide as separate patches? > Please don't get me wrong: I've tested the patch and the test cases you provided all seem to work as intended. So I'm very grateful for your work! I just think that splitting up the patch into smaller chunks might increase the chances of it getting reviews and eventually making it into the mainline codebase. > There is your very detailed PDF that describes your ideas and most of the changes, of course. But its great detail also has it's downsides, at least for me: I found it hard to keep track of everything. As an example, I noticed the following change in your patch: > -------------- cut --------------------- diff -Naur ./fluidsynth-1.1.6\src\rvoice\fluid_adsr_env.h ./fluid-polymono-0003\src\rvoice\fluid_adsr_env.h --- ./fluidsynth-1.1.6\src\rvoice\fluid_adsr_env.h Tue May 19 12:27:02 2015 +++ ./fluid-polymono-0003\src\rvoice\fluid_adsr_env.h Wed Jun 22 13:37:59 2016 @@ -95,9 +95,11 @@ env->section++; env->count = 0; } + else env->count++; env->val = x; - env->count++; + + } /* This one cannot be inlined since it is referenced in -------------- cut --------------------- > > I wondered for a long time if you were fixing a bug here or adding new functionality. Only just now I had another look through the PDF and actually found the place where you mention that it is a bugfix. In my opinion, this type of change should really be in a separate patch, so that it can be fixed quickly even if your larger feature is delayed. > All the best, > > Marcus > _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
