copying all reaper items for reaper-play?

[Leon-Focker]

Hey @mdedwards, @rubenphilipp found and fixed a minor bug for reaper-play today, which stems from copying all reaper-items when calling make-reaper-file (that is because it is an sc-list, which, if you don't change it, copies its data when initializing). The bug happened due to an incomplete copy function for the reaper-items. However, I was wondering if it might be favorable not to copy all of the reaper-items that are created with reaper-play (as there could be a lot of them and I can't think of a scenario, in which one would want to only edit the item, not the item in the file). Maybe there is a good reason? If not, I would propose setting the copy argument to nil when calling make-reaper-file in reaper-play.

[mdedwards]

Hmm, I'd be curious to see how you produced and noticed that bug. Can you send code?

[rubenphilipp]

Certainly I can elaborate on this. I simply invoked reaper-play with the sc-object from second law, just using the code from the examples-dir. There, I noticed that none of the Reaper items in the generated rpp-file are panned as expected (i.e. the VOLPAN for the items are 1.0 0.0 1.0 -1 throughout the file). I inspected the reaper-items local var in reaper-play slippery-chicken.lsp (line 6003[^1]) and found that there, the pan slots in the generated reaper-items are set as expected. The culprit appeared, at the first glance, to be make-reaper-file as the the following simple test – derived from the call to make-reaper-file in reaper-play (slippery-chicken.lsp, ll. 6007--6011) – showed that when instantiating a new reaper-file object and storing the list of reaper-items to the :data slot the values of :pan in the reaper-items get lost respectively are all set to the initform.

(let* ((ri (loop repeat 3
         collect
         (make-reaper-item (file-from-sc-dir
                    "doc/manual/resources/test-sndfile-2.aiff")
                   :pan (1- (random 2.0)))))
       (rf (make-reaper-file 'rf ri)))
  rf)

As reaper-file is a child of sclist, the values of the :data slot (where the reaper-items are stored) will be cloned unless the slot-value of :copy is NIL (which is not the case in the case of reaper-file, as far as I know). Thus the copy method is invoked to the newly created reaper-file object in the example above. The problem here appeared to be the specialized reaper-item/clone-with-new-class method (reaper.lsp, ll. 226--237), where the :pan slot is omitted. Adding a setf for the :pan slot (as done in 119fd31f23b067ee0d5050303a160b79fb24f7b8) appears to fix the problem.

[^1]: Referring to commit 649e6f635c63a4dd3a11ddc023aa52e5fa9b4986 here.

[mdedwards]

Aha, OK I see what you mean. Clearly I was a little too quick at claiming reaper-play was working. Thanks so much to you and Leon for not only finding this but fixing it too! Cheers, Michael

On 13. Dec 2023, at 14:31, Ruben Philipp @.***> wrote:

Certainly I can elaborate on this. I simply invoked reaper-play with the sc-object from second law, just using the code from the examples-dir. There, I noticed that none of the Reaper items in the generated rpp-file are panned as expected (i.e. the VOLPAN for the items are 1.0 0.0 1.0 -1 throughout the file). I inspected the reaper-items local var in reaper-play slippery-chicken.lsp (line 60031 <x-msg://154/#user-content-fn-1-e97497de94b1f3396d3a1ec9f6d566d9>) and found that there, the pan slots in the generated reaper-items are set as expected. The culprit appeared, at the first glance, to be make-reaper-file as the the following simple test – derived from the call to make-reaper-file in reaper-play (slippery-chicken.lsp, ll. 6007--6011) – showed that when instantiating a new reaper-file object and storing the list of reaper-items to the :data slot the values of :pan in the reaper-items get lost respectively are all set to the initform.

(let* ((ri (loop repeat 3 collect (make-reaper-item (file-from-sc-dir "doc/manual/resources/test-sndfile-2.aiff") :pan (random 1.0)))) (rf (make-reaper-file 'rf ri))) rf) As reaper-file is a child of sclist, the values of the :data slot (where the reaper-items are stored) will be cloned unless the slot-value of :copy is NIL (which is not the case in the case of reaper-file, as far as I know). Thus the copy method is invoked to the newly created reaper-file object in the example above. The problem here appeared to be the specialized reaper-item/clone-with-new-class method (reaper.lsp, ll. 226--237), where the :pan slot is omitted. Adding a setf for the :pan slot appears to fix the problem.

Footnotes

Referring to commit 649e6f6 https://github.com/mdedwards/slippery-chicken/commit/649e6f635c63a4dd3a11ddc023aa52e5fa9b4986 here. ↩ <x-msg://154/#user-content-fnref-1-e97497de94b1f3396d3a1ec9f6d566d9> — Reply to this email directly, view it on GitHub https://github.com/mdedwards/slippery-chicken/issues/72#issuecomment-1853923963, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3IOIV25REN5E4XFIU544DYJGU3HAVCNFSM6AAAAABAR3NOFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTHEZDGOJWGM. You are receiving this because you were mentioned.

[rubenphilipp]

Things happen… I'm happy that you shared your work on reaper-play. Hope that Cockos won't make any unforeseeable changes to the file structure in the future.

Greetings Ruben