[Petri-foo-devel] petri-foo development

[James M. <jwm...@gm...>]

Hi

I have felt a bit frustrated with Petri-Foo development over the past
few weeks*.

Some shortcomings of Petri-Foo were discovered via a discussion on
Linux Audio User. I mentioned Inverted velocity tracking as part of a
solution for dealing with a lack of sample-layers in Petri-Foo.
Inverted velocity tracking doesn't actually work in Petri-Foo
currently. The use of inverted-velocity tracking as a solution for
mapping one sample for low-velocities, and another for high-velocities
(with mid-velocity playing both at half their amplitude) is broken
anyway (ie, there would be a complete loss of the quiet-to-loud effect
that the range of velocity values normally have).

The other thing I wanted to do was modulation of sample play + loop
points via an offset parameter which can be modulated much like other
parameters. It required tedious amounts of copy/paste/edit coding for
setting/getting of the patch data and then of the gui data.
Additionally, I feel unsatisfied that note-on events are the only way
to trigger sample playback. I wanted to give LFOs (amongst other
things) the ability to trigger sample playback - which for
completeness means envelopes must be triggerable by this method also.
Unfortunately the LFOs use integer math wizardry meaning that there's
no easy way to detect a phase reset/wraparound (or no method i know
that i would find easy ;-).

The code I began working on In the midi_cc_for_switches branch is also
incomplete and I stumbled over an awkward problem: mono/polymode has
it's own special way of turning mono/poly on/off so it's no as a
simple as on/off. So I'm unsure what to do there. I am tempted to
ignore it and let the user choose a non-standard controller to do it
as a simple on/off effect but this would probably only confuse/annoy.


don't forget the tracker on sf.net. see
https://sourceforge.net/tracker/?group_id=404816


james.



* Have completely lost track of time in coding-la-la-land.