Hi,
I made a loop which produces a list of chord-seq. (This list I input in to a maquette.) In the loop (among other parameters) I connected set-port to the chord-seq (self-output), but the port in the outcomming list of chord-seqs remains always (default) 0. How can I (can I?) force “set-port” to evaluate inside the loop (for each iteration)? (It is always one port and channel per loop.)
Many regards!
Aliser
Hi Aliser
Maybe if you send your loop to see why this doesn’t work ?
Best
K
Hi aliser,
I think this will work out, i can;t say since your loop is not connected to anything.
Best
K
the-loop1.omp (7.86 KB)
Dear Karim,
I am sorry, but the patch you’ve send to me does not work.
I think there may be a problem with inheriting the port information from one to the next chord-seq.
In my experience the connected chord-seq will only inherit the port information if the previous chord-seq is evaluated (with set-port) and locked. (If the previous chord-seq is unlocked, the port of the next connected chord-seq is restored to default 0 port.) It would be much easier if score-objects would have separate slot for port.
I am sending the patch but now with input data.
Please, let me know if you find the solution. (I am in a middle of a composing of piece where I would really need to be able to set ports.)
Thank you very much for your effort and kindness!
Aliser
the-loop2.omp (21.9 KB)
Hi Aliser. There seems to be a half-way solution to set LPort in objects, but for some reason it has been left unfinished.
You can try a version of set-port which returns its modified object:
(defmethod! set-port ((self container) port)
(loop for item in (inside self) do (set-port item port))
self)In case this brakes other things just make it into a regular function:
(defun my-set-port (container port)
(loop for item in (inside container) do (set-port item port))
container)-anders
Dear Anders,
Thank you very much! It solves the problem.
I’ve used the function version. (I don’t know how do add methods to already existing functions in OM. I’ve never tried.)
For me it is more useful solution when set-port returns self with changed port, rather then if it (only) sends a midi-message! (But I suppose it depends what for do you need it.)
Thank you once more!
Aliser
Hello – Indeed, set-port modifies its input but does not return it.
I don’t really see a reason why it is like this, and would be tempted to change this in future releases.
Actually the more logical (in order to repect the data-flow paradigm and not to produce side effects-, would be to return a modified copy of the object.