Om-internal-sound and memory

[charlesneimog]

Hi, again Jean,

I have a question.

Is it possible to clear the memory that om-sharp is using after save the or in the hard drive?

I am working on a piece, and I am organizing samples with voices, but how my voice is now I little big, I very often receive the message:

Error while evaluating the box sound-seq-list: failed to allocate a foreign object of size 6584208 [allocation static] When I evaluate the patch more than once. The object sound-seq-list works with this code:

(defun sound-seq-list (sounds fade-bewteen-sound)

(let*  (
    (action1 (sound-seq (first sounds) (second sounds) fade-bewteen-sound))
    (action2 (if 
                (>  (length (x-append action1 sounds)) 2)
                (x-append action1 (last-n sounds (- (length sounds) 2)))
                action1)))

    (if (< (length action2) 2)
            (first action2)
            (setf sounds (build-sound-sequence-fun action2 fade-bewteen-sound)))))

Maybe this code it's not good. I dont know. Could you help me? Thank you!

[j-bresson]

Hallo Charles. In principle the audio buffer memory of the sounds created with sound-seq is automatically cleared when the sounds are garbage-collected. What does build-sound-sequence-fun do ?

[charlesneimog]

It works like sound-seq but allows me to work with more than 2 sounds.

For example in a list (#<sound 2369E843> #<sound 2369B61F> #<sound 2369E653> #<sound 2369F5A7> #<sound 236A04C3> #<sound 2369B9A3>), build-sound-sequence-fun will build one sound #<sound 238745A7> that contains all the sounds of the list (#<sound 2369E843> #<sound 2369B61F> #<sound 2369E653> #<sound 2369F5A7> #<sound 236A04C3> #<sound 2369B9A3>). in sequence.

But here is my problem, after I evaluate this function and save this new sound, the memory is not cleared. I think that is because I do not know how do this 'garbage-collected'.

Maybe I must to indicate to OM# that this memory is not important after save the sound? But I do not know how I do that.

This is an example.

[j-bresson]

Can you try with reduce ?

This Lisp function allows you to apply a function to a list, applying each result to the successive next elements. It just requires passing sound-seq as a lambda function:

Let me know if the same memory issues arise with it.

(ps. I was interested to see the code of build-sound-sequence-fun)

[charlesneimog]

Yes, I already tried it, and I had the same problem. I already tried:

• Save the sound after the processing without lock the boxes.
• Use the reduce with sound-seq (It is a little bit more slow in my computer).
• And now I am using the defmethod!

(defmethod! sound-seq-list ((sound list) &optional (fade-bewteen-sound 0.001))
:initvals ' (NIL)
:indoc ' ("Sdif-File.")
:icon 'om-ckn
:doc ""

(om-print "Aguarde alguns segundos!" "Verbose")

(let* (
      (action1 (build-sound-sequence-fun sound fade-bewteen-sound)))

  (save-sound action1 (outfile (string+ "temp-sound" (list->string-fun (list (om::om-random 0 9999999))) ".wav")))))

But the memory it is not cleared.

Sorry, the code is that above, I forgot to change the name.

(defun build-sound-sequence-fun (sounds fade-bewteen-sound)

(let*  (
    (action1 (sound-seq (first sounds) (second sounds) fade-bewteen-sound))
    (action2 (if 
                (>  (length (x-append action1 sounds)) 2)
                (x-append action1 (last-n sounds (- (length sounds) 2)))
                action1)))

    (if (< (length action2) 2)
            (first action2)
            (setf sounds (build-sound-sequence-fun action2 fade-bewteen-sound)))))

[j-bresson]

Ok, I think you could simplify your recursion code a little bit, but this is not the point here. Are you using big audio files ? Only 6 sounds of reasonable/small sizes shouldn't be a problem...
I could suggest a few things:

• Force-call garbage collection using (gc-all) : does it make a difference ?
• Compile your function: (compile #'build-sound-sequence-fun)

[charlesneimog]

Hi Jean,

It does not work, gc-all clear just 10MB of ram. I changed my work to make the sequences and mix with SOX, based in the OM-SOX. It's working now.

Thank you!

[j-bresson]

Good that you got a solution with om-sox!

I'd like to keep investigating this: What is the approximate size of audio files you are using ?

OM# on Windows is a 32-bit application, so it has limited resources. Also, recursive processes tend to consume a lot of these since audio buffers remain allocated on the stack until the recursion returns. Loops are usually more efficient in this respect.

[charlesneimog]

I am working with small samples (like 900Kb) but put it in sequence (the sequence is the problem), so in the end, my audio has a size of 15Mb or more.

[charlesneimog]

One more question/curiosity, why is it not possible to compile OM# in 64bits?

[j-bresson]

I am working with small samples (like 900Kb) but put it in sequence (the sequence is the problem), so in the end, my audio has a size of 15Mb or more.

On the example above there seemed to be only 6 samples in the sequence, right ? 🤔

[j-bresson]

One more question/curiosity, why is it not possible to compile OM# in 64bits?

💰 → http://www.lispworks.com/buy/prices-2a.html

[charlesneimog]

I am working with small samples (like 900Kb) but put it in sequence (the sequence is the problem), so in the end, my audio has a size of 15Mb or more.

On the example above there seemed to be only 6 samples in the sequence, right ? 🤔

Yes, but in my real piece, I am working with a lot of samples (146 samples and increasing). It is with this work that I am having some problems.

Normally, with 2 evaluations I already have the message with allocation problem.