Hi!
I hope you are all well and safe!
The function Merger doesn’t inherit the port information from the incoming chord-seqs. (The output (merged) chord-seq is automatically transferred to port 0.)
Is it possible to solve this, so that the original port info remains in the output score object?
Does anybody has a patch with the appropriate method for Merger? (Karim, Jean, Anders?)
(I don’t dare to mess around with the OM built-in functions.)
All the best and stay safe!
Aliser
Hi Aliser. Nothing is impossible, remember we’re talking lisp here… 
Here’s a hack, the resulting chord-seq should keep the port info per note, but i haven’t checked what happens when you want to playback more than one chord-seq at a time (implicit merging and stuff…):
merge-chordseq-w-ports.lisp (2.5 KB)
Hi,
Sorry for bringing back an old topic, but it is important for me to find a solution.
As you can see from the previous correspondence, Anders kindly helped me by sending the new method for merger that enables me to merge chord-seq-w-ports, what for am I very thankful. [chord-seq-w(ith)-port is chord-seq with an additional input/output for ports, which enables manipulation and/or automatisation of port-slot of a chord-seq. The topic about chord-seq-w-port may be found at: Port-list to chord-seq? ]
Yet, I stepped in to a new problem when trying to merge chord-seq-w-ports. The “normal” merger function does not inherit the port information from the merged chord-seqs. The lisp patch merge-cordseq-w-ports sent by Anders in the previous mail of this correspondence merges only first notes of different ports. (In previous OM versions Anders’s patch worked well on a simpler examples but in OM7.0 it does not. May the OM version be the reason?)
Anyway, I am looking for a method that would make merger inherit ports from the incoming chord-seqs. I would be very thankful to get help. (My programming skills do not allow me to mess with the OM predefined classes.)
All the best!
Ališer
Dear Aliser,
Tested Ander’s patch here:
merge-chordseq-w-ports.lisp (2.5 KB)
and works well for me on om7.0.
Please be sure to put the file above in your init file (inside OM 7.0.app) then restart OM.
After testing it more, I will consider to integrate it in OM’s code in the next coming version.
Best
K
Dear Karim,
Thank you for answering! (Man can always count on you! Thank you for that immensely!)
I wondered myself why the Anders’s patch suddenly does not work in OM7.0, because it has worked previously. I tried again to put his patch in Init folder, but when merging, it shows the same strange behaviour. (With Anders’s patch it merges only the first notes of each chord-seq and without it, it merges properly, but all notes are merged to port 0.)
Therefore I am sending an example patch. Please let me know if you get the same strange behaviour!
Since I am using subclass of chord-seq, chord-seq-w-port, I am also sending the lisp patch for that subclass. (Perhaps there is some collision between chord-seq-w-ports and merge-chordseq-w-ports?)
Many thanks to Anders and you for help, kindness and patience!
merge-with-ports.omp (45.9 KB)
chord-seq-w-port.lisp (264 Bytes)
All the best!
Ališer
Hi Alister,
Ok, the merger works fine on chord-seq’s and not on chord-seq-w-port. The reason apparently is that it misses some methods (a lot) to set ports of this new class. Inheritance also is a problem with this class. The two classes in your first example are in fact chord-seq-w-port and not chord-seqs as it appears to be (number of standard in/out slots).
So what i believe the problem is, that either you have some missing code from Anders, or this is unfinished coding. Why don’t you just use standard chord-seq and then setting ports then. By the way, can you remind me why you do use ports specifically. Is it related in microtuning. I ask because i am also interested in this topic.
Best
K
Dear Karim,
It seems that there is a problem with port output of the subclass chord-seq-w-port: it receives and transfers directly inputed data to the output, but it does not output port data inherited from previous instances of chord-seq (received through self-input).
Anyway, I made a patch that solves the problem (for merging chord-seqs with port inheritance) so I am sending it. (It still needs subclass chord-seq-w-port in the Init folder, but at the input and output there may be “normal” chord-seqs".)
chord-seq-merger-w-ports.omp (77.8 KB)
I hope you didn’t invest too much time in solving this problem!
I was trying earlier to use function set-port with normal chord-seq, but it didn’t really work. If you have a solution, please let me know! Anyway, to have a subclass of chord-seq with port-slot was functioning and was much handier for manipulation. (Maybe it wouldn’t be bad to have fully functioning subclass of chord-seq with port-slot?)
I use so many ports in order to have the possibility for microtonal playback with more instruments. Since OM uses 4 channels per instrument for microtonal playback, I need multiple instances of soft-instruments (plug-ins) which I load to Logic. In Logic I route IAC buses to tracks and in OM ports to IAC buses. (Hence I use Logic as playback engine for OM.) Of course, using multiple ports enables also playback in tunings different then 1/4 or 1/8 ET.
Thank you once more!
All the best!
Ališer
Dear Aliser,
Yes indeed. I am actually working on having a poly midi play in 16th tone using ports. That’s why i asked 
And the good news is that i am debugging things in OM. I will seriously consider the port issue for chord-seqs. However, we should be really carefull not ot break compatibility. That is the main reason that makes thing difficult. Coding it is easy, but testing needs to be thouroughly conducted.
Now actually looking on the set-port issue, and apparently there seems to be a bug. Will let you know asap.
BEst
K
Hi Aliser,
After retesting set-port, i confirm this works under these conditions:
Now i am considering to add the port slot in the standard chord-seq, however this needs some time and testing in order to make this work. Should dive beneath the surface and check everything out inorder to make this work at one condition NOT to break OM’s compatibility.
Will keep you informed.
Best
K
