A function for unpacking a locked `ombox`

[Dumaiu]

How are you gentlemen?

I’m learning OpenMusic, and I am interested in whether there’s a function for refactoring a locked factory box into an equivalent unlocked circuit. If not, I should like to write one.
I’ll explain the workflow I’m looking for more specifically. Suppose I’m working on a patch p with a box b containing one of the higher-level compositional elements, such as voice or poly. If I enter notes manually, the box will be locked. I wish to then call a function to produce a patch p’ and box b’ such that b and b’ have the same output, but b’ is unlocked. This will entail

1. Factoring the input data out from b
2. Creating new patch elements to hold these data, and linking them as inputs to b’
3. Unlocking b’.

(1) is about following slot references, while (2) seems to be just graphical widgetry. (3) is probably a funcall; all I’ve figured out so far is that when a box is locked the value of the allow-lock slot changes to "x".

I’m sure none of these is especially tough by itself, and I’m pretty good with CL, but if someone could point me to the relevant parts of the OM API, it’d be very helpful. Thanks!

Jonathan J-S

[haddad]

Hi Jonathan,

I am not sure i understand the problem here. When you refer to an ombox, is it the graphical representation of methods and functions, or you mean the factories like VOICE, POLY etc… which are classes by the way. Or are you meaning by this a patch abstraction in a patch ?

Anyhow one lead on “factoring” (1 and 2) (if i get you right here), is using ctrl+shift+eval (win, linux) or cmd+shift+eval (mac) and this will give you an instance of your factory list or whatever.

Now for unblocking, you just have to select your blocked item (function, factory, etc.) and type ‘b’.

Hope this helps.

Best
K

[Dumaiu]

I am not sure i understand the problem here.

My fault; I should have made clear that I seek a Lisp utility to do something I already know how to do by hand. As a concrete example, let’s say I start with a patch like this:

This is a voice stored in an OMBoxEditCall, and there are four slots whose data differ from the default values, which I would lose if I were to unlock the box: tempo, tree, inside, and tonalité. In Lisp all things are possible, so I want to write a function which will generate this patch:

I made this one manually by copying the necessary values into input boxes in the new patch (except for tonalité, which I had to (setf) into the new chord-seq using the Lisp editor).

The advantage of the second patch, clearly, is that more of the motivic information is exposed for algorithmic manipulation.

When you refer to an ombox, is it the graphical representation of methods and functions, or you mean the factories like VOICE, POLY etc…

OM’s being a visual wrapper over Lisp, so the answer is probably ‘both’, necessarily; to make a program to reproduce the example above, one needs to get the slot data from the voice inside the OMBox. But one also needs to know the API for adding new boxframes graphically, and the documentation I’ve found at

OM Architecture

is limited.

Or are you meaning by this a patch abstraction in a patch ?

That’s a technique I don’t know yet.

---

I hope this elucidates what I’m trying to do. I’m sorry I’m inconsistent with my terminology–‘unpacking’, ‘refactoring’–whatever; I don’t know what to call it. Kind of the visual equivalent of the Lisp function (macroexpand-1).

-Jonathan

PS: In my example, the “unpacked” box in the second picture contains another locked box that holds the chord-seq, implying that the unpacking or unwrapping could be handled recursively.

[haddad]

Dear Jonathan,

I am starting to understand. The trouble is that setf macro is not available in Patch mode. So there exists a trick to do what u want without messing in the code. In order to change your initial voice, first,

1. copy it, because we will destructively change it.
2. shift+drag the voice. You should see the slots box of voice equivalent to the setf of the slots.
3. connect it to the voice copy
4. in the example below, i will change the chords of my voice, keeping the rhythm tree and tempo changes intact, by connecting the output of inside connected to the chord-seq, and to the slot of slots box.
5. evaluate. You have setf the chord slots of your voice.

By the way the documentation you refer to is as you say incomplete unfortunately and not up to date. If you need to look into the code concerning this, go to the /code/kernel/ folder.

Best
K

Patch 30.omp (23.7 KB)

[haddad]

ADDENDUM:

Sorry my bad, an even more elegant solution (without copying your initial voice). We use the clone method:

patch 31.omp (24.0 KB)

Best
K

[Dumaiu]

@haddad

We use the clone method:

The icon’s a sheep! Someone has a sense of humor.

You showed me a couple of good techniques here. According to the docs in basicboxes.lisp, the slots-box is the preferred way. I probably shouldn’t be using setf. However, they also provide get-slot | set-slot. I probably won’t be happy until I’ve compacted this whole process into a context-menu entry.

@haddad

If you need to look into the code concerning this, go to the /code/kernel/ folder.

That is very helpful. The performdrop.lisp file shows how graphical frames are added through code, though I haven’t had time to study it hard.

In the meantime, here’s a perhaps odd question. If I use Lisp to create factory boxes without graphical containers, can they still work? Like, can they still be evaluated and send messages to each other?
Normally one wouldn’t want to do that, but it might be useful while I’m learning.

-Jonathan

[haddad]

Hi Dumaiu

@Dumaiu

If I use Lisp to create factory boxes without graphical containers, can they still work?

Well it depends on what you call factory boxes. Factory boxes ARE the graphical representation of an om class such as voice, etc…

You can still use while in om package:

(make-instance 'voice :tree '(? (((4 4) ( 1 1 1 1))))) :tempo 60) etc...

You will get a voice class.

best
K