On Wed, 6 Mar 2024 19:06:38 +0100
ichthyo wrote:
>On 06.03.24 11:20, Will Godfrey wrote:
>> It was me that changed the effect's graph to horizontal lines. This was to
>> get rid of those weird discontinuities, which seem to be due to the FLTK
>> drawing routines not handling lines that are more t
On 06.03.24 11:20, Will Godfrey wrote:
It was me that changed the effect's graph to horizontal lines. This was to
get rid of those weird discontinuities, which seem to be due to the FLTK
drawing routines not handling lines that are more than one pixel wide and
offset vertically by fractional amou
Hi Hermann,
I was busy ferrying a non-driving friend around yesterday so didn't get much
time to look at the code then.
It was me that changed the effect's graph to horizontal lines. This was to get
rid of those weird discontinuities, which seem to be due to the FLTK drawing
routines not handling
Hi Will,
meanwhile I learned a bit more about LV2 and managed to debug the
LV2 plugin while running under Qtractor. This allowed me to see
how the threads and the UI-start are actually handled.
Basically everything was operating as I had expected from theory.
This allowed me then to do those (
Hi Will,
Just managed to get the EQ graph switched over to the new system!!
So, up to now, the Heffalumps seem to be rather friendly and tame
and only slightly stubborn at times...
This change involves a trade-off; while the original code directly called
into the core with a frequency precise
On Sun, 3 Mar 2024 02:22:53 +0100
ichthyo wrote:
>On 01.03.24 19:22, Will Godfrey wrote:
>> I've spent quite a lot of time trying to get rid of these loops, but it's
>> rather like wack-a-mole, and very easy to accidentally create new ones :(
>>
>> If the commands have come from anywhere *other*
On 01.03.24 19:22, Will Godfrey wrote:
I've spent quite a lot of time trying to get rid of these loops, but it's
rather like wack-a-mole, and very easy to accidentally create new ones :(
If the commands have come from anywhere *other* than a specific knob/slider
etc, then that control should be
I've spent quite a lot of time trying to get rid of these loops, but it's
rather like wack-a-mole, and very easy to accidentally create new ones :(
If the commands have come from anywhere *other* than a specific knob/slider
etc, then that control should be updated.
--
Will J Godfrey
On 28.02.24 21:35, ichthyo wrote:
... Other parts of the system do still access the core direcly, and where
this especially creates all kinds of strange effects (no pun intended) is in
the Part-Effects, since the control widgets to select the effect-Nr, type and
routing are not part of the Effect
On 07.02.24 01:07, ichthyo wrote:
* implemented: have MirrorData blocks in the UI connected properly
* unimplemented: trigger push update + use the data from the MirrorData
block
On 21.02.24 02:51, ichthyo wrote:
...now focussing on the aspect of state updates. While I'm still somewhat
stru
10 matches
Mail list logo
