Where is Lisp code box in OM6's menu?

[fredvoisin]

Dear Karim and Didier,

in effect, I just checked on a good old mac that the ‘lisp-code-box’ exists in PWGL. It was probably there in Patchwork, I remember I used it quite soon and often.
The ‘lispfunction’ box in OM has exactly same functionnalities than the ‘code-box’ (whith no lisp-) in PWGL: you can write (only) lambda expressions and inputs connectors are graphically updated according to its arguments list.

But these two kind of way to write lisp code are not equivalent.
In the first way (Patchwork way), one can define lisp functions, methods, etc, not only anonymous functions (lambda).
In the second way, a lambda has to be defined, and all lisp functions defined using, for instance a ‘defun’ statement seems to be not recognized into the patch.
I really like (need) the first way… it is very convenient.

Bests.

[fredvoisin]

Hi Didier,
This sounds strange, I use to write lisp in the LW Lisp editor attached to OM in both OSX and Linux.
But I never use defmedthod! directly… At that point - for testing and developping, I use standard lisp defun/defmethod statements.
May be you just need to declare such a specific OM method in the main lisp file in a OM Lisp library, as if it’s part of the Lib’s menu ?

[didierdebril]

Thank you Karim, I am preparing a PDF with the screenshots of the Mac and the PC with which it works.
Best.
Didier

[didierdebril]

Hello Fred, I have the same problem on the Mac with defun too. I finish a little job and make a PDF with screenshots from the Mac and PC.

[fredvoisin]

Lispfunction seems to not provide the functionality I’m looking for, see my previous screenshot. Here is a screenshot in PWGL the lisp-code-box I’m looking for, different than lispfunction (code-box).
The lisp-code-box is represented in the patch with the “(Lisp)” icone, in grey at the top of the patch. When double-cliking on it, it opens the “Text-Editor” window, the one in the middle on the right side of the screenshot, and the embeded code is loaded when opening the patch.

I know I’m touching a taboo in mixing up everything here, bit as you know anthroplogists really like taboos

Bests.

[haddad]

Dear Fred, dear Didier,

For the time being you can always open an editor from the listener (ctrl+n) and type in your code:

1. One thing is mandatory in order to use this code in a OM patch:
   (in-package :om)

2. Just type ctrl+y to evaluate all your code and call your functions and methods.

3. you can even put your .lisp file in your init folder at startup.

I thought you knew this already (??)

Best
K

[haddad]

addendum, (for fred): if you want to see the code connected to your custom code, just select the box and type e.

Best
K

[fredvoisin]

Dear Karim,

yes, we know it of course.
The point is to make the lisp code embeded into any patch so that there is no risk for files dependancies which can be outdated or lost…
It can be very usefull for (captain) ad-hoc projects which do not need to develop a dedicated library… In such a case a patch can be self-sufficient.

[bresson]

Hello Fred and al.,
A few complementary options in OM are:

• Put your lisp file(s) in your workspace’s “user” folder so everything it contains gets loaded with the workspace.

• Use a TEXTFILE box and evaluate all its contents it using the eval-textfile function.

This second one seems the closest option to what you are looking for (embedding the code within the patch file itself), although you still need to evaluate it manually.

Jean

[bresson]

Also (as a side note:), one thing to be aware of with this “evaluate code within a patch” idea (either with TextFile or with in PWGL’s lisp-code-box I guess?) , is that the patch that contains this generates side effects: it potentially defines (or redefines) functions, and is therefore likely to change how some other (visual) programs behave, depending on whether they are executed before or after this patch. This is something we try to avoid in general.

[bresson]

ps. you can also define functions inside the lambda
(but you also need to evaluate it yourself)

[fredvoisin]

Dear Jean,

Using defun declarations inside a lambda (in a lispfunction box) or using a textfile box do not work when loading OM and then the patch: the function defined in that ways become ‘dead’. And after reloading and evaluating the definitions, the boxes remain dead and need to be changed.
May be this last behavior could be adapted: the boxes could appear as dead before evaluating the definitions and be alive again after evaluating the lambda or textfile containng the definitions ? These should be quite intuitive…

Anyway, puting the lisp code in the workspace’s ‘user" folder works
And, at the end, it seems more intuitive than embeding lisp defintions into a patch, it’s a middle way before developping a dedicated library (shouldn’ this way have the same side effects of 'evaluating code within a patch ?).
The only point I would suggest in that way, is to not use the same ‘lisp’ simple icon as the standard lisp icons but to use a specific icon which may explicitly tell the user that the function she is using is specific to its own workspace - or why not using same lisp icone but with a different color ?

All the best.
Fred

[bresson]

@fredvoisin

Using defun declarations inside a lambda (in a lispfunction box) or using a textfile box do not work when loading OM and then the patch: the function defined in that ways become ‘dead’.

Yes, as I said, the code is not loaded automatically and you need to do it “manually” after the patch is loaded.

@fredvoisin

And after reloading and evaluating the definitions, the boxes remain dead and need to be changed.

You can also just reload the patch (right-click or “File” menu + “Last saved”).

[bresson]

@fredvoisin

Anyway, puting the lisp code in the workspace’s ‘user" folder works
And, at the end, it seems more intuitive than embeding lisp defintions into a patch, it’s a middle way before developping a dedicated library (shouldn’ this way have the same side effects of 'evaluating code within a patch ?).

Not really, because in this case the code is loaded at the beginning, when starting the session, and shared by all patches right away (not depending on whether you have open some given patches in a given order before to use another patch).

[bresson]

@fredvoisin

The only point I would suggest in that way, is to not use the same ‘lisp’ simple icon as the standard lisp icons but to use a specific icon which may explicitly tell the user that the function she is using is specific to its own workspace - or why not using same lisp icone but with a different color ?

Good point. Not necessarily straightforward though… (how do you know? someties a function can be redefined at different places, or a generic function can have methods anywhere, too, etc.)

[fredvoisin]

@bresson

Good point. Not necessarily straightforward though… (how do you know? someties a function can be redefined at different places, or a generic function can have methods anywhere, too, etc.)

Maybe by automatically instanciating the icon acccording to a dedicated lisp memory package such as a ‘ws-package’ ?

[didierdebril]

Hello Jean,
“Put your lisp file(s) in your workspace’s “user” folder so everything it contains gets loaded with the workspace.”
I was wondering about the best location. I just tested in the / User workspace and it works, the functions are active when you open OM. Thank you for that clarification. Best. Didier

[didierdebril]

Bonjour Karim, j’écris en français car mon anglais n’est vraiment pas terrible. Bon, déjà, jusqu’alors je travaillais surtout avec les fonctions natives et abstractions (patchs internes) mais l’utilisation d’Opusmodus, et sa programmation via des scripts et qui propose un puissant éditeur de partitions, m’a amené à m’intéresser à la programmation de petits scripts en Lisp et de comprendre la syntaxe de ce dernier. Du coup, j’ai testé avec OM sur des PC sous windows 7 et 10 sur lesquels j’ai effectué plusieurs essais. Puis, j’ai essayé de les reporter sur mon Mac. Et là, surprise, alors que la création de fonctions via les “lambda functions” ne pose aucun problème, j’ai constaté après les évaluations dans le Lisp Listener puis l’insertion de la fonction dans le Patch que les fonctions n’étaient pas reconnues.
J’ai créé un PDF avec des copies d’écran, avec en première page les fonctions créées avec la version OM 17 windows; en page 2, l’exemple du Manuel OM 6 (defun myfunction (a b c) (let ((x (+ a 5))) ( x (/ b c ))* créé avec OM 17 version Mac mais qui n’est pas reconnu ainsi qu’un autre exemple sur le calcul d’une fréquence Hz créé avec une lambda fonction qui, elle, est reconnue, et le même calcul avec une fonction Lisp reconnue par OM-Shape.
En page 3, j’ai mis les messages d’erreur d’OM; en page 4, des petits codes de fonctions effectifs avec la version Windows et OM Shape Mac mais refusés par ma version Mac OM 17; et en page 4 l’exemple de calcul d’une table d’indice et de fréquences Hz calculé avec OM et Opusmodus mais sur lequel je bute pour créer une fonction incluant le calcul itératif.
J’espère que c’est assez clair.
Best. Didier
OMFonctionsLispMac&PCEn.pdf (628.2 KB)

[haddad]

Cher Didier,

D’abord il serait bien de creer un nouveau Topic pour cela. Car ca na plus rien avoir avec “where is Lisp code box…”
Mais ceci n’est pas grave.

La demarche a suivre, pour utiliser du code lisp dans OM, est bien tres simple. Il suffit:

1. de creer in fichier .lisp (a partir du listener avec New, pomme N).
2. dans son en-tete mettre:
   (in-package :om)

et puis le code.
Exemple:

Le “(in-package :om)” est tres important. Car sans cela, OM ne sera pas au courrant que cette fonction lui est destinee.

sinon, domage que tes fonctions soient en pdf, sinon je les aurais copies dans ce fichier. Apres tu peux soit:

1. evaluer le fichier, (ctrl+y) (ca serait pour la session courrante)
2. le mettre dans le dossier init de OM (ca serait pour tous les workspaces)
3. ou dans le dossier user d’un workspace, (ca serait jsute local pour ce workspace specifiquement).

Sinoj pour les pages 4 et 5, je n’ai pas tres bien compris. Si tu peux on traite cela dans un nouveau topic. Mais je ne m’occupe pas de opusmodus ni de omsharp, cela apparement n’est qu’une affaire de lisp. Que voudrais-tu vraiment faire ? pas trop compris. Si possible une question a la fois.

amities
K

[didierdebril]

Bonjour Karim,
Merci pour cette première réponse qui m’a permis de résoudre mon problème avec le Mac. Il manquait donc le (in-package :om) pour que la fonction soit reconnue. Et sa sauvegarde dans le dossier User de mon workspace fait qu’elle est bien active quand on lance Om et le patch. Je note donc une différence avec la version windows d’OM. Cette dernière accepte les fonctions même sans l’insertion du code introductif (in-package :om) et c’est ce qui m’amenait à ne pas comprendre pourquoi je n’arrivais pas à créer la même fonction avec le même code dans un patch de mon Mac. Mais maintenant, j’utiliserais ce in-package :om dans les deux distributions. Donc, un grand merci.

Sinon, du coup la page 4 est nulle et non avenue et pour la 5, je vais ouvrir un nouveau sujet pour cette création d’une table affichant les indices/ratios et fréquences dans un tempérament et comme je le fais de façon classique avec les fonctions d’OM. Je bute pour une fonction Lisp dans le calcul itératif des indices et des fréquences Hz, le fichier en Lisp pour Opusmodus était juste à titre d’exemple.
Best. Didier