Thank you Karim, I am preparing a PDF with the screenshots of the Mac and the PC with which it works.
Best.
Didier
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.
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.
Dear Fred, dear Didier,
For the time being you can always open an editor from the listener (ctrl+n) and type in your code:
-
One thing is mandatory in order to use this code in a OM patch:
(in-package :om) -
Just type ctrl+y to evaluate all your code and call your functions and methods.
-
you can even put your .lisp file in your init folder at startup.
I thought you knew this already (??)
Best
K
addendum, (for fred): if you want to see the code connected to your custom code, just select the box and type e.
Best
K
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.
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
TEXTFILEbox and evaluate all its contents it using theeval-textfilefunction.
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
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.
1 Like
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
Yes, as I said, the code is not loaded automatically and you need to do it “manually” after the patch is loaded.
You can also just reload the patch (right-click or “File” menu + “Last saved”).
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).
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’ ?
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
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)
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:
- de creer in fichier .lisp (a partir du listener avec New, pomme N).
- 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:
- evaluer le fichier, (ctrl+y) (ca serait pour la session courrante)
- le mettre dans le dossier init de OM (ca serait pour tous les workspaces)
- 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
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
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)
Ce n’est pas normal. De toute facon il faut mettre le in-package… c’est mieux.
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.
Oui oui, absolument. Ca ne doit pas etre difficile. Juste expliquer ce que tu attends de la fonction.
Amities
K
In my experience, for info, I don’t use om package declaration on either Mac or Linux.
To me, it seems that om package is required if you use ‘defmethod!’, which is a OM macro, not a standard Lisp one.
In such a context, i.e. out of an OM library dev, I just use standard lisp using ‘defun’ or ‘defmethod’ and it works as well as with declaring om package, more or less icons and some OM default facilities (such as opening the doc in a browser etc).
Cheers.