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.

I FINALLY made it work, it's now as reliable and foolproof as i can patch it!

midisettingsperpatch.pd

audiosettingsperpatch.pd

I spent quite some time to make it clean and well working, so i'm not sure it will save me time in the end, but i'm sure it can save you some, so please use it! Bear in mind you HAVE to modify it to contain your own audio and midi devices. Their names can be found using audiosettings and midisettings objects.

Each patch containing this one, if correctly modified, will create and send to pd the correct message to tell it to put which device on which "slot" of the audio and midi settings menus.

I also made a patch for audiosettings, which sets the audio interface of your choice, with all the appropriate settings, plus another "plan B" setting in case the main audio interface is missing.

Once properly set up, you only have to worry about plugging your audio and midi devices before launching Pd. What a relief in terms of time and stress, especially in live situations!

Sadly it needs Loopmidi or something similar to work, with as much virtual midi devices as the real ones you'll be using: if one or several devices are missing, the virtual ones will replace them in the midi settings, so it doesn't ruin the order of devices. I named them DUMMYIN\ 1 and DUMMYOUT\ 1 to 5 because i don't have more than 5 midi devices plugged at once. you have to create these DUMMY things in loopmidi to get this patch to work.

(I tried with one dummy midi device in and one dummy out, but it doesn't work if two real midi devices are missing in a row: pd apparently won't let you have twice the same device on consecutive slots)

the next steps would be to make it more user friendly, by sending messages to it, so it can be used in several different projects without being edited inside.

The most convenient solution would be to modify Pd source code to make these settings behave differently, by assigning a UNIQUE number to each device, being plugged or not, or accepting messages that contain the order of devices BY THEIR NAME and not a randomly assigned number... then it would be possible to store a simple midi and audiosettings message in each patch.

Thx for reading

#proudofmyself #nobodycaresaboutthisbutyouwhoareherebecauseofthesamepreoblem