-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathNOTES
84 lines (61 loc) · 3.18 KB
/
NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
NOTES
# TODO
[x] case insensitive client and port name matches
## future
[] periodically check clients and ports for name and capability changes
(since, due to kernel bugs, the change events are never sent), and if there
are changes, remove and re-add the relevant ports
N.B.: Not clear this is really needed, since we don't see any applications
that really change port names or capabilities after being created. See the
code in MidiMinder::handleSeqEvent for details about client name changes.
[] figure out how to fsync in Files::writeFile()
[] ? on soft reset, we could just scan activeConnections and only disconnect
those that the rules wouldn't put back; and then, when adding back the
ports, be careful to not try to reconnect connections that remainded
(or just ignore the ALSA Seq connection error) - this would ensure no
disruption of connections when switching profiles where a connection is
in both the old and new profile. Really may not be worth the effort!
[] make connection-logic-test something that could be used during packaging
- needs to not write files, nor use ALSA
[-] optimize saving observedRules
- no longer really needed, as never saved more than once per event
[] ? some way to be graceful about aseqdump - we shouldn't be saving
those connections as observed rules
[] ? unicode detection in Term
[] ? future possible options for connect/disconnect
--force, --interactive, --dry-run
[] ? in list command and view command, group ports by type??
# DAW NOTES
PureData
- When changing number of MIDI ports, deletes them all
then re-adds them. This works for us.
- OMG - it sets the name of the client AFTER it creates the ports
Renoise
- Has separate clients for In and Out!
- Has non-exported ports first, so user ports don't start from zero
- Adds and removes ports, at times willy-nilly. If you connect a port
to a device in the app, it deletes its port, recreates it named with
the name of the other port, and then connects them. This seems okay
with midiminder
- ? Perhaps we want a "ignore client" list - since Renoise does a fine
job of managing MIDI ports on it's own.
- Interestingly: no output ports other than sync!!
Reaper
- Normally talks to raw MIDI devices
- Has one "virtual" in and one "virtual" out port, each uses its own
ALSA client (!), and the clients are named "Client-128" and "Client-129",
the ports are named "Virtual RawMIDI" no matter what they are renamed in
the UI.
LMMS
- Lets users pick other ALSA ports as MIDI in/out for specific tracks
- Will create a port and connect it for each such assignment
- Doesn't seem to notice when connections are changed outside of it
-
Ardour
- Creates a ton of clients: A pair for each other ALSA port, each client
has one port in or out. These are connected to each of the other
ports. BUT, none of the Ardour ports are marked subs - so no idea how
these connections are made.
[] caused amidiminder to generate ALSA Seq error -2 in get client info
[] need to make sure these ports are completely and correctly ignored
bitwig - only x86-64 available