Hello,
I would like to get puredata to place midi devices in the same order at startup, or at project startup. I already made [ pd midi-dialog ( messages with some success, as long as you keep your usb midi devices plugged the same way. This is when it gets frustrating, as pd or windows rearranges midi devices randomly when you unplug them and replug them between sessions. As i use pd on a laptop, i unplug midi devices often to do other stuff than puredata with it. i would like puredata to use the same midi devices and placed in the same order in the midi dialog, to make [ pd midi-dialog( messages relevant. Don't know if i'm clear, thanks for reading!

Paul

@Rachitic-dada Lucarda has updated "mediasettings" for 64-bit Pd and it can be found through deken with a search for "midisettings"
It used to be available bundled in extended.
It will give you the device names in the order reported, and so with a lot of work it should be possible to build a "wrapper" patch that then re-routes midi..... [notein] [noteout] etc. to bespoke (say) [mynotein] [mynoteout] abstractions that put everything back in the correct order.

If you can make it universal (by adding device names as arguments to the wrapper abstraction) then there might be others that will find it useful.
David.

Thank you @whale-av ! i did this little patch where you have to enter the names of your midi devices, in the order you want them in the midi settings. I have to test it on other configurations to see if it works properly. I'm unhappy with the pipe objects but that was seemingly the best option to avoid double triggering, or missing info in the pack ffff... route object don't seem to bang its outputs from right to left.

I also struggle to install mediasettings, and i currently have to open the midi-settings-help patch to get pd to acknowledge midi-settings object. Sorry for the noobism!

hope this will help others someday, if this does work reliably it's a big step forward for me, to be able to use pd in live configurations with many midi devices. In case of a bug/crash it's gonna save some time and stress !

brouillon midi settings.pd

PS you might also wanna adjust the [ 4 6 ( message at the end of the instruction sent to pd. i don't know what i t means but i noticed it was there every time i printed midi settings, so i put it. if anyone knows...

@Rachitic-dada That is a much better idea..... resetting the midi dialog....... avoiding any changes to existing patches.
You probably need [pipe] because the incoming messages from [midisettings] are in the wrong order for your patch.
You could hold the "in" and "out" parts in [list] objects and bang them into the final midi-dialog message with a bang from [loadbang]
so
[[loadbang]
[t b b]
| |
| |
| your patch
|
bang messages in order

It should then wait for [mediasettings] to complete its operation and fill all [list] objects before they are banged into the midi-dialog message....... and you can remove the [pipe] objects.
David.

thank you very much! so the later bang in t b b will wait all calculation to be done with the first?
I'm having a big problem with one of my midi devices, which name finishes by eight spaces, and i can't route it, even with \\\\. as it ends with spaces, i think it confuses route object. I tried to change its name via windows but it's even more upsetting and inefficient. Any ideas? i will search answers to that and post them here if found, except if it's too much out of topic.

@Rachitic-dada USBDeview.exe is a useful portable program for seeing what is happening with ports in Windows.
I cannot test your patch as I have no midi devices.
There is a chance they are not ascii spaces (32) but some other character, as I would expect Pd to just drop spaces at the end of the name.

You can use [list fromsymbol] connected to a [print] to see the numeric values of the characters.
And you should be able to use that list of numbers sent to [list tosymbol] to set the right inlet of a [route] object
You would have to have a chain of [route] objects (right rejection outlets connected to the next one) rather than a single one with multiple arguments though....

And...... yes...... a [t b b] will not send the left side bang until everything that followed the right side bang has been completed. There is right to left ordering in Pd for object outlets so the same rules apply for [t b b b], [list], every object in fact...... http://puredata.info/docs/manuals/pd/x2.htm

David.

@Rachitic-dada Ps. I forgot to mention that you have to set the route object to accept symbols on its right inlet........ you can use for example [route dummy] and then feed your required symbol to the right inlet to change "dummy" for what you need.
David.