< Back to IRCAM Forum

Problems with permut-rand

OpenMusic
#1

Hi,

I am using OM6.6.1, MacOS 10.7.4.

Long time ago I made a patch Conditional (random) permutation which permutates the elements of a sublists so that the last element of the preceeding list is not equal to the first element of the next list.

In other words:
List: ((1 2)(1 2 3)(1 2 3 4))
the result may be ((2 1)(3 1 2)(1 4 3 2)),
but not E.g. ((2 1) (1 3 2)(2 4 3 1))

This patch was functioning perfectly in previous versions of OM (5), but now suddenly I receive an error message: The variable permut-random 193-138 is unbound.

What may be a reason for that? Is there a bug?

In order to make my question more clear, I am sending pics of patch(es) in attachments!

Many greetings!

Aliser

Image-1.png

#2

Please try to download the last version of OM (6.8 on ForumNet)
Do you still have this problem then ?
Best,
Jean

#3

Dear Jean,

I downloaded OM 6.8 and I still get the same error, then I tried with OM 6.5.1 and it works. So presumably there is a bug in the random-permut function starting from OM 6.

Many greetings!

Aliser

#4

I think this is not a bug in permut random but with the use of the eval-once mode inside the om-loop
Can you send the patch ?

FYI, there is an incompatibility between the use of ev-once and the possibility to add an “init-do” box in the omloop
We’ve been trying to deal with it for a while without much success. My guess is that there is something related here.

#5

Dear Jean,

Here the patch!

Greetings!

conditional-tree-permut.omp (4.75 KB)

#6

indeed you walk here on a slippery ground in OMloops : ev-once boxes connected to init, final, or iteration boxes.

here is a test fix.
please copy attached file in OM 6.8/patches/ and restart
I am not sure it does not break something else in the loop. keep me posted !

omloop-test-fix.lisp (1.97 KB)

#7

Dear Jean,

Now it is working with your fix-patch. Thank you very much!
I learned only graphical programing in OM, so I had no idea that I’m on a slippery ground. Can you suggest another less slippery method that would do the job?

Many greetings!

Aliser

#8

no, you’re doing very well !
you should not worry about internal implementation issues :slight_smile: