< Back to IRCAM Forum

Object-dur and select

OpenMusic
#1

hello om-ers,

I’m experiencing some problems with SELECT. it happens when selecting consecutive sections of a multi-seq-chord. although OBJECT-DUR reports the duration, let’s say 20000, when I put 20000 as for the 2nd input of select I get an error reporting that the object duration is less. object-dur value is consistent with what can be seen in the mseq editor selection.
please see the screenshot.
has anyone encountered this kind of problem?
btw, I’m still on 6.12 and hsierra.
thanks in advance for any info,
perti

04
Screenshot 2019-06-14 20.59.04.png1134×621 47.7 KB

#2

I’m replying myself just to report that now I see that SELECT is taking the end value from a different event, not the last one. is taking the last duration of the 3rd ‘track’ and not the actual latest value taking into account all other inner lists.
hope this is clear enough.
thanks again,
perti

#3

Dea Petri,

Glad that you found out the problem. But just to say, and this applies to all users, in such cases , it is better to send a patch instead of a screenshot, that is if you need some help. It is more efficient for debbuging.

Best
K

#4

sorry about that. here is attached a simple patch that illustrates the problem.
merci,
perti
test-for-select.omp (15.1 KB)

#5

Hi Perti.

The current version of the #'select method for mutli-seqs expects the multi-seq to have some content within the time window which is asked for.

In your case, the first chord-seq inside the multi-seq ends at 4000 ms, the second at 5000, so select doesn’t have anything to return after 4000 ms, yielding the alert box instead.

#6

Dear Perti

the solution is to set all chords in the multiseq such as they end synchronically. And yes, you should be aware that you should fix your time boundaries such as they are non null time. The best is to fix the select method behavior.

Best
K

#7

thanks Anders for your reply.
the length of every chord-seq was deliberately short because I suspected that the last end value taken was that of the shortest chord-seq. now I know why. good to know.
I’ll try some workaround.
thanks again, it helps a lot.
thank you Karim. the total time in every part cannot be set to end synchronically as they come from another patch generating them like a kind of canon with different (and random) durations.
greetings,
perti.

#8

Not sure if changing the way select works on multi-seqs is the right thing.

@haddad, what should the method return for the chord seqs where there’s no content? Just an empty chord-seq lasting the expected duration?

You can test this version of select (for chord-seq’s), the only change is taking away the ‘within-bounds’ check, so it may provoke errors elsewhere:

(defmethod* select ((self chord-seq) (start number) (end number))
  (let ((chords 
         (loop for onset in (Lonset self)
            for chord in (inside self)
            when (and (>= onset start) (< onset end))
            collect (list (- onset start) chord))))
    (if chords
	(mki (type-of self) 
             :LMidic (mapcar 'second chords)
             :Lonset  (append (mapcar 'first chords) (list (- end start)))
             :legato 0)
	(mki (type-of self)
             :Lonset (list 0 (- end start))
             :Lmidic NIL))))
#9

@anders :

  1. For a chord-seq it could return nil. nil is better than an error massage
    2)For a multi-seq it returns evidently other chord-seq with content or else nil

Best

1 Like
#10

@anders it’s working ok, at least in my original patch (not the one I submitted, was deleted) which was where I noted the unexpected results.
I’m not sure if I understood you, but I tested it with multi-chord-seqs and it’s ok.
thank you again once more,
regards,
perti

#11

FYI I have just integrated this change in the OM sources.
In fututre releases there will be no more time-bounds check / error message returned, and an empty chord-seq if the selection window is out-of-bounds.

1 Like
#12

thank you mr. bresson,
regards,
perti