Extensable commands to extensable objects in another thread defined across crates, how to?

I want to have a tree of objects that implement a specific trait and I want this tree to live in another thread and be able to update parameters of these objects. I will be writing a library and would like users of the library (which will include me via other crates) to be able to create their own object types, which also implement that specific trait, and send them into this thread to get put into that tree and also be able to have parameters updated. My initial set of objects might include an audio oscillator that accepts a command to update its frequency with a f32 but maybe in the future someone wants to update their own object with something like i32 or f64 or some enumeration or struct type.

I'm wondering if, with the current state of safe rust, ideally stable but at-least sooner than later to be made stable [I'm thinking this excludes specialization], there is a way to implement a command or visitor pattern that allows me to, down the line, add new command types with new types of parameters after the initial command or visitor interface is defined?

With specialization it looks like you can do it just fine, but specialization still feels a ways off from stability, and I should test to see if this works across crates:
https://github.com/rust-unofficial/patterns/issues/55#issuecomment-298214625

I don't see why the tree API couldn't just take Arc<Mutex<dyn Trait>>> where the Trait is your interface that anything can implement and then be passed to the Tree?

Are you suggesting that I somehow keep a handle to each original object and build up the tree via? Arc<Mutex<dyn Trait>>>

Okay, I have 2 additional constraints: I can't use mutexes in the tree thread [as it will drive realtime audio] and I'd like to minimize the paths to update parameters so i can easily implement an undo interface.

I could see an option where each object that wants updates has its own channel that provides it with updates but that seems needlessly heavy as far as allocation and also makes the potential for an undo interface insane.

I'm guessing I don't fully understand your requirements. I probably shouldn't have bothered to comment in that case.