Am 07.03.22 um 22:40 schrieb Will Godfrey:
.... and FLTK lets you have buttons labels etc. superimposed on each other and shuffled just using 'show' and 'hide'. I've got fairly used to FLTKs quirks so if you want to get on with other stuff I can sort that out.
Thanks for offering that, probably we'll follow-up on that topic later, because it seems indicated to sort out the general control logic first. Just had some look into the details of PADnote, and I'm afraid that actually implementing cross-fade might become somewhat hairy (while simple in principle). The reason is that the wavetable use is very closely interwoven with the internal note state (and moreover there is also cubic interpolation, which also has its complexities). Currently I see two challenging issues: - we must be careful not to add overhead to the regular code path, since cross-fades are rare events, while wavetable interpolation comprises the "hot" inner loop (where most of the computation time is spent) - as interpolation proceeds, the internal reading position is updated incrementally, and thus we can not just easily calculate a second buffer with the samples from the "other" wavetable. At least not from within PADnote::noteout() - rebuilding the wavetable can change pretty much any parameters, including number of tables, tablesize and base frequencies. Thus it is not possible just to calculate both interpolations in parallel. Thus, what we actually need is to make kind of a new note instance for the new wavetable, and then seamlessly blend the samples generated from both. Which unfortunately would place us into the same situation as with Legato notes, which -- as it stands right now -- were tricked and shoehorned into the basic design (with the fixed poliphony array of notes) and thus turned into quite a coding mess. Basically our dilemma is: - we can not effort to duplicate all the allocations and structures just for the rare case of computing a cross fade - we do need a second set of note-state data for the "other" wavetable, since both do not match in the general case - we do not want to code a separate case for changing the wavetable layout, since in fact the existing code can handle both cases nicely. - we have no framework just to add further "computation tasks" dynamically on demand, because the whole SynthEngine was built around a fixed layout of components and parts and note positions. Somehow, we need to hook in /between/ the part, which computes N PADnotes, and the hot inner loop within that PADnote instance, but without expanding and complicating the regular code path too much. Guess I have to sleep a night over that one .... -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
