how to return runtime defined amount and type of midi2 messages.

[laenzlinger]

How would one use this trait for an application that might create multiple messages triggered by an event (e.g. a button)

Is there some support for an iterator approach available where the caller would get an iterator of messages produces by the event?

[laenzlinger]

I am struggling with my rust knowledge. Sorry for this. Any help is very much appreciated. In addition to the question above, I am struggling already with returning a single generic message from a function. The specific returned message can be pre-configured on the device at runtime -> it is not yet known at compile time. Which type of this create would such a function return?

[BenLeadbetter]

Hello!

How would one use this trait for an application that might create multiple messages triggered by an event?

TLDR: UmpMessage<[u32; 4]> is a pretty good choice.

Which trait are you referring to? There are some traits which capture common functionality, but in this case you probably want to have such events generate one of the aggregate message types. Either UmpMessage or perhaps channel_voice2::ChannelVoice2 or something, if you don't need all the different message types.

All messages are generic over their backing buffer. This means you'll need choose the buffer type for your generated messages. [u32; 4] will cover most cases. For the fancier messages (e.i. data messages or text) you'll need more space - a Vec<u32> would always work if you need such things.

[BenLeadbetter]

The specific returned message can be pre-configured on the device at runtime -> it is not yet known at compile time.

I think this is also solved with the aggregate message types, e.g. UmpMessage or one of the sub aggregate messages e.g. channel_voice2::ChannelVoice2

[laenzlinger]

Thank you for your answer. At the moment I want to send ChannelVoice1 or MMC (Sysex7?) types of messages. However, in future also other (MIDI2) types of messages might also be implemented. But this has no priority. I just want to develop using a midi crate which has a future with MIDI 2.0. I just found this crate a few days ago and still trying to learn how its built and can be used.

I forgot to mention, that I am developing for a micro controller (no_std environment)

how would you recommend to define a function that generates such messages triggered by user actions (concrete message to be generated is based on the internal state of the device)

Would you pass a mut buffer into the function?

How can I keep the design flexible for future extensions (more message types)

[laenzlinger]

my current attempt looks like this:

impl Button {
    pub fn handle<B>(&mut self, action: Action) -> Option<BytesMessage<B>>
    where
        B: Buffer<Unit = u8> + BufferMut + BufferDefault + BufferResize,
    {
         // depending on the configuration of the Button and the action input, 
         // a different message is created. Can be Sysex or ChannelVoice message
    }

This compiles but I can not use this with a [u8; 3] buffer because it does not implement the BufferResize trait.

How would you suggest to change the fn interface?

I am sorry for this question I know I still have to learn a lot about Rust.

[BenLeadbetter]

You could use the BufferTryResize trait instead of BufferResize. This will allow you to do sysex operations and also support the full feature set for the channel voice messages.

[laenzlinger]

Thanks a lot for this hint with BufferTryResize This really helped.

I am now trying an interface like the following:

impl Button {
    pub fn handle<B>(&mut self, action: Action) -> Result<Option<BytesMessage<B>>, BufferOverflow>
    where
        B: Buffer<Unit = u8> + BufferMut + BufferDefault + BufferTryResize,
    {
         // depending on the state of the button, create new messages
         // e.g.:   let mut m = NoteOn::<B>::try_new()?;
    }
}

Then on the caller side i can extract the data with data() function.

This seems to work and also allows different handling of messages (in my case I need to handle sysex messages slighly different than ChannelVoice1 messages

I am not sure if this makes sense? If you have better suggestions, please let me know

[laenzlinger]

What is not clear to me: How do I find out how large the resulting buffer should be that has to be sent over the wire?

For example a TimingClock message would be one byte, but the buffer returned by data() seems to be two bytes long.

[BenLeadbetter]

data() should always return the size of the message buffer. TimingClock::data should therefore return a buffer size 1.

It seems there's a bug in this area - thanks for flagging it! I've created a pull request to fix the issue. I'll put out a hotfix release today hopefully. Please do let me know if there are any other issues like this?

[laenzlinger]

Ok, this makes the above approach valid again. I was scared that this this information (length) would have to be retreived from somewhere else which would have been a bit more inconvenient. But anyways did not find it. So fixing it, so that the client can rely on data to have the right size sounds great.

[BenLeadbetter]

If you pin to version 0.6.4 the issue should be fixed.

[laenzlinger]

Yes I can confirm that upgrading to 0.6.4 fixes the length issue with realtime messages.

Could you maybe provide some feedback to the API that was proposed above. Does this make sense for you? With my current knowledge, this would allow to dynamically extend the buffer, if the underlying implementation allows. The try_new method would do that, if I understood the code correctly.

To also support MIDI 2 messages the interface would have to be changed. Is my understanding correct?

[BenLeadbetter]

Sorry about the delayed response. I wanted to put out a feature release (0.7.0) before getting back to you.

It's a little tricky to critique your implementation without knowing more of the context of your application, but I can give it a go.

You say that this handler on the button needs to dynamically create midi messages of different types? In that case a generic api on the handler function might not be the best since it will force you to decide a backing buffer at compile time. So in order to remove the generic we need to choose an appropriate backing buffer. We need something which can accommodate large messages and also something no_std friendly (otherwise a Vec would do nicely). [u8; 3] is not going to be much good if you want to create sysex messages too.

With the new_with_buffer constructors (new in 0.7.0) we can use a &mut [u8], so long as your application memory model will allow it:

use midi2::{channel_voice1::*, prelude::*, sysex7::*};

enum Action {
    Foo,
    Bar,
}

fn handle(
    action: Action,
    buffer: &mut [u8],
) -> Result<BytesMessage<&mut [u8]>, midi2::error::BufferOverflow> {
    match action {
        Action::Foo => {
            let mut message = NoteOn::try_new_with_buffer(buffer)?;
            message.set_note_number(u7::new(0x3));
            message.set_velocity(u7::new(0x5));
            Ok(message.into())
        }
        Action::Bar => {
            let mut message = Sysex7::try_new_with_buffer(buffer)?;
            message.try_set_payload((0x0..0x20).map(u7::new))?;
            Ok(message.into())
        }
    }
}

fn main() {
    let mut message_buffer = [0x00u8; 128];
    println!("{:?}", handle(Action::Foo, &mut message_buffer[..]).unwrap().data());
    println!("{:?}", handle(Action::Bar, &mut message_buffer[..]).unwrap().data());
}

Alternatively you could using a simple array for backing buffer (BytesMessage<[u8; 64]>), but you'd be wasting memory for the CV messages.