Axoloti contrib merging

the title says it all.

how should future axoloti contrib folder merging work? do akso users get a monthly update or weekly? is there any work involved to port objects or is it a simple merge?

issues i see:

-what if somebody creates an object in axoloti-contrib with the same name as somebody on the akso-contrib folder?
-what if akso firmware diverges more from axoloti, is the plan to be backwards compatible?
-what about the other way around, objects written for akso, will they work on axoloti? (currently and in the future)

maybe it could be an option to have two contrib folders, one that simply gets merged from axoloti and another one with akso objects. maybe we could even access the axoloti-contrib directly.

The vast majority of objects are directly compatible because they’re essentially mathematical, they don’t directly access hardware resources. Those can easily be merged in either direction at whatever frequency we like.

Incompatibility arises when objects directly access low level hardware resources. It shouldn’t even be designed this way. There needs to be a general API for accessing resources from object implementations that doesn’t know about the underlying processor.

Longer term, the Akso object format is going to change completely. The patcher is going to change completely as well. I don’t see making decisions in those areas based on trying to maintain compatibility with the existing Axoloti distribution directly. I think what makes sense is to allow people to run the Akso distribution on Axoloti hardware if they choose and be able to drive both pieces of hardware from the same patcher. That way we can have direct control over firmware and object compatibility; the firmware would keep track of what resources are available for each target. If people want to backport particular objects to the legacy Axoloti distribution, that will be possible.

I’m not totally satisfied with the contrib sharing mechanism itself. I think exposing git details in the app is a mistake; most users don’t care about that at all. I see having more of a “sign in” mechanism somewhat like VCV Rack that is integrated with the object browser web interface where you can subscribe to objects and store work. Sharing objects should not require authorization to commit directly to a Git repository.

This is a longer discussion. Will return with more thoughts later!