How do I properly protect MemoryWriters in an encapsulation?

Question

When I create a Sound for encapsulation that includes some kind of memory writer (eg. MemoryWriter or FeedbackLoopInput/Output) I have been using UniqueMemoryWriterRecordingNames and CancelUniqueMemoryWriterRecordingNames around my Sound to protect the memory. 

The pattern I have adopted is if my Sound has a memory writer I'll put a UMWRN Sound at the far right, and a CUMWRN at every "entry" point of my Sound. If my Sound has two audio input parameters then I will use two CUMWRN's, each just to the right of the VariableSound input in my flow. 

Here's a simple pretend example:

 

The CUMWRN's are needed because if I don't include them then any Sound flow that feeds in to my encapsulation will also have its MemoryWriters renamed which could cause problems for any users of my encapsulation. 

Up until now I have assumed I only need to put CUMWRN's on the audio inputs to my encapsulation. But I've just done a few experiments that seem to suggest that if I paste a Sound into a Capytalk parameter of my encapsulation that Sound will also be under the influence of the UNMWRN. 

Here's an example:

 

This is the flow for an encapsulated Sound. In this example I have one audio input (the "input" Sound), a Capytalk input that feeds in to the audio channel ("CapytalkInput", a Constant containing ?CapytalkInput) and also a ?Level parameter. 

Once encapsulated the Sound looks like this:

 

I then test this Sound by feeding a MemoryWriter in to one of the parameters of my encapsulation and try to play back the contents of the MemoryWriter using a Sample on a parallel branch (the MemoryWriter and Sample use the same memory location name, "recording"):

 

If I feed the MemoryWriter in to the encapsulated Sound's audio Input parameter then everything works fine. The unique recording name function has been cancelled and the Sample player can see the recording from the MemoryWriter. 

If I paste the MemoryWriter into either the CapytalkInput or the Level parameter then I get an error:

 

The MemoryWriter's recording name has been renamed. 

It gets more intriguing if I paste the MemoryWriter into both the audio Input parameter and the CapytalkInput:

In this instance the Sample Sound is playing back the signal that is being fed into the MemoryWriter. But the error message is suggesting that there's a MemoryWriter with a recording name of "recording_umwrn_0" which is never read. That suggests to me that there are now two MemoryWriters which is not what I was expecting. 

 

In this simple example I can see how I would cancel the renaming function for the audio Input and the CapytalkInput parameter by moving the CUMWRN to the right of the Mixer in the encapsulation so it would cancel for both inputs. But I don't see how I should turn off renaming for all Capytalk parameters in my encapsulated Sound (ie. "?Level" in this example). 

 

What is the proper method of protecting MemoryWriter recording names inside an encapsulation while not causing issues for any Sound upstream?

 

Answer 1

There are several ways to do this:

• Paste a CancelUniqueMemoryWriterNames into the field (in your example, Level) and put the Sound you wanted to paste into that CancelUniqueMemoryWriterNames Sound.
• Make the names of the MemoryWriter wavetables parameters of the user class and avoid using CancelUniqueMemoryWriterNames within the class itself.
• Use the new (in Kyma 7.35) Capytalk message cancelUniqueMemoryWriterRecordingNames. You would use this message wherever a user class parameter is used and the use is not to the left of a CancelUniqueMemoryWriterRecordingNames Sound (for example, ?Level, in your question).

Answer 2

Not sure if it might help, but I am into the habit of managing my own unique names for feedback and MWs, to avoid difficult to debug build errors.

I use something like

{'recording'&?uniqueID}

?uniqueID is assigned from a script as `Number nextUniqueNumber`