I believe that as long uuid and sha are not conflicting with other objects, you can ignore the warnings.
But the best solution 'd be a functional object editor inside Axoloti.
Improvements/Wishes for the patcher
How to code Axoloti objects
The ability to determine the layout of Subpatch modules. At the moment, they just sort of turn into really long skinny modules, I'd like to be able to controll where the controll on parent items are placed, and the length/width of the parent module. :> Having a lot of fun with the axoloti btw!
Display content of table
This could be an option in the table (alloc) menu that shows a window with a list of the current values in the table.
Being able to edit these values (when not 'live') would be nice too.
Keyboard shortcuts for window (ex. on mac)
Keyboard - cmd+k
File Manager - cmd+f
Remote - cmd+r
more single letter for direct access (like m -MIDI)
f- filter
g- gain/vca
l-lfo
….
One minor thing:
I usually do my patching on a laptop with a maximum display resolution of 1366x768. At that resolution, help/library falls off of the screen, so nothing after /timer is accessible. It would be nice to tweak the GUI so that the dropdown menus adapted to the resolution of the machine the patcher is running on (so in this case, display two columns instead of letting the list fall off the bottom).
One little thing i have to report is the following: the int32.mini parameter box does not allow negative numbers to be displayed correctly, for example if i define such object with the code
<int32.mini name="i0" noLabel="true"> <MinValue i="-36"/> <MaxValue i="36"/>
the result is that i have a box which can correctly select values from -36 to 36, but since the size is quite small, negative numbers smaller than -9 can't be displayed correctly (if i write -19 i'll then be able to read only -1, if i write -24 i'll read -2 etc...)
Since resizing the box or the text is hardly a good solution, one possible workaround could be to change the background color for negative numbers
disp/ lays on a subpatcher....like parameter on parent, why is there not something like display on parent?
i am dreaming of a midi clock generator, where i can feed 24 ppq to midiclock
also a resolution 96 ppq would be nice
I think sending midi clock should be integrated in a master clock object rather than being something separate. Because midi clock is supposed to be steady.
Unless you need to create irregular midi clock to test the response of other devices to jittery clock. But that's not a common need.
I think midi/out/clock needs improved scaling, real world unit annotation, and a tempo modulation inlet.
Internal versus external midi clock source? I think it is quite a different situation, a tempo parameter or modulation inlet do not matter if it's slaving to an external clock.
It would be really nice to be able to save all used subpatches along with the main patch... Something like "save patch + all subpatches".