I think the vertical zoom-in factor of pianoroll is too limited.
Should be enlarged a bit.
PLease explain more about what you mean …
Please, check this out, i posed it in rc1 thread also…same problem…looks like one of those “fixed resolution” insted of “percentage of available canvas” things, if that makes any sense 
.
This bug remained.
Mint 22.2, Cinnamon, 1366x768 (this laptop’s max.resolution).
Every other window in Ardour is completely fine, but…
- when double clicking on a midi event to get in pianoroll, it opens up like this, and there’s no way to shrink it, maximize it to fit the screen size, or to see the bottom panel.
I tried everything in OS settings and Ardour GUI settings, but it just remains the same.
I expect that any plugins that still use Gtk2 as GUI will no longer work.
I am surprised that Fedora still packages them to begin with.
Ouuuu i see!.. That’s why many of kx repositories plugins gave me errors last night with messages like “cannot write to GUI” etc…Many of them still do use Gtk2 according to Google.
And i tought i messed something up again while fiddling with OS
They do not still package them since Fedora 38. Somehow they got left over on my system since then and went unnoticed.
The Invada plugins are still available for Fedora through Yann Collet’s widely used “Audinux” COPR repository.
@x42 just curious, wasn’t one of the reasons to fork gtk2 as ytk not to prevent plugin GUIs from messing with that of the host?
No, the reason was to allow distros that drop gtk2 to still build and provide Ardour, and as added benefit allow us to customize gtk (e.g. add multi-touch support).
Since gtk API and ABI needs to match this also the final nail in the coffin for plugins that depend on system-wide gtk2+ libraries. – This issue that we always had with binary builds of Ardours (vs disto versions).
Maybe falktx’s wrapper to process isolate plugins to keep Calf working for a bit longer helps here too?!
1 Like
I’ve just checked out the latest nightly and love your solution to the layering of the controls on the piano roll. It’s very elegant and makes a lot more sense.
Could the addition of user selected lanes be considered. I do a lot of piano MIDI editing and it would be really useful to be able to see CC64 Sustain (for example) as one of these lanes. I realise that the bottom set of buttons could get really busy if too much is added. Maybe have the 4 standard buttons preselected but when pressed a drop down list of other available codes is displayed.
As always, thanks for your continued work
I’ve been checking out cue recording for a live looping setup.
My first beat is often recorded but plays back silent. My guess is I hit the key slightly early, placing the note-on event just before the clip start. Manually quantizing fixes it, but that is not usable for a live performance
Is there a setting for input/recording quantize that automatically fixes these early notes during the recording process?
1 Like
Please file a bug report at tracker.ardour.org and attach an archive of a misbehaving session so that I can take a look.
I don’t see the session archive attached?
Sorry, I thought the screenshots were enough, I’ve tried to update the issue including the session but I reached the allowed activity limit. However, strangely, the first beat does sound correctly after saving and reopening the session. You can see the actual issue occurring in the attached video.
(I will upload the session file shortly, once the limit resets)
EDIT: session attached