PortSpec should be an enum, not a trait about rust-jack HOT 9 CLOSED

PortSpec is a trait so that other libraries can create their own types beyond the built-in "audio" and "midi". Though I see how supporting the built in types is more important.

Another convenience of having each be its own type is that each Port gets its own type as well.
This allows for this type safety:

AudioInSpec -> Port<AudioInSpec> -> AudioInPort wrapper
AudioOutSpec -> Port<AudioOutSpec> -> AudioOutPort wrapper
MidiInSpec -> Port<MidiInSpec> -> MidiInPort wrapper

In the above case, having the types allows for specific wrappers for each port.
AudioInPort is similar to a readable f32 slice
AudioOutPort is similar to a writeable f32 slice
MidiInPort is an iterable over midi signals.

If the Spec was no longer a different type for each port, then the conversions would not be as straight forward, it would be.

Spec::AudioIn -> Port -> AudioInPort
Spec::AudioOut -> Port -> AudioOutPort
Spec::MidiIn -> Port -> MidiInPort

// This last case isn't a valid transformation, so it should panic at
// runtime instead of being checked at compile time.
Spec::AudioIn -> Port -> AudioOutPort

from rust-jack.

In your use case, can you just use a custom Spec for your enum?

pub enum BuiltInSpecs {
    AudioIn,
    AudioOut,
    MidiIn,
    MidiOut,
}

impl PortSpec for BuiltInSpecs {
   ...
}

For convenience, the wrappers would have to take a port with any spec.

impl<'a> AudioOutPort<'a> {
    pub fn new_from_generic_port(port: &'a mut Port<T>, ps: &'a ProcessScope) -> Err<Self, err> {
        // check that port type is audio
        // check that direction is output
        // create wrapper
    }
}

from rust-jack.

Or, maybe easier:

pub enum BuiltInSpecs {
  AudioIn(AudioInSpec),
  AudioOut(AudioOutSpec),
  MidiIn(MidiInSpec),
  MidiOut(MidiOutSpec),
}

pub enum BuiltInPorts {
    AudioIn(Port<AudioInSpec>),
    AudioOut(Port<AudioOutSpec>),
    ...
}

from rust-jack.

Yeah I guess I understand the extensibility it brings.
I suppose i can make a wrapper enum.
I only need it for the specs themselves though
The ports being their own struct is fine by me.

My problem is that if I want to make a wrapper around Port, i need to mess with generics and it gets messy.

For example, this is not allowed since they are two different types:

let spec = if is_output { j::AudioOutSpec } else { j::AudioInSpec };

let spec = if is_output { j::Spec::AudioOut } else { j::Spec::AudioIn }; // this would work because theyre both the same type

from rust-jack.

Another probleam im having is how do I make a function that returns a port that can be of any spec?

fn register_port(&self, ...) -> j::Port</* has to be a type here at compile time */> {}

from rust-jack.

And another annoyance is that i cannot reuse the same spec twice in port registration:

let portl = cli.register_port(&pnl, spec).unwrap();
let portr = cli.register_port(&pnr, spec).unwrap(); // I don't own spec anymore so this doesn't compile!

This is probably a seperate issue though, spec should be passed by reference here...

from rust-jack.

About the last annoyance thing, maybe there should be a #[derive(Clone, Copy)] for the specs?

from rust-jack.

Ended up finding a way: Snowlabs/Jamyx#1 (comment)

Thanks for the help!

Should the issue be renamed to the #[derive(Copy, Clone)] thing?

from rust-jack.

This has been fully resolved now...
2628107

from rust-jack.