Besides you will notice when evaluating an om-inspect object connected to the self of the voice, a window ‘inspecting’ opens and among the list of components (classes I guess) you’ll find another INSIDE instance including a list of measures, and each measure includes an INSIDE class which includes groups which includes an other INSIDE class which includes chords and finally notes !
Ok, thank you, this is really interesting!
As for ‘clone’, it’s only that I realize that the patch seems to be working the same with or without it, so I was wondering what was its specific utility…
Thank you!
Jimmie
So we need more light here…
Hi there! Just to complement a little bit Karim’s point and the overall discussion:
As you know, all OM is written in Lisp, and (almost) all Lisp can be brought graphic into an OM visual patch. Not all is completely straightforward though 
OM patches represent functional expressions, which to be consistent should have no side effect: you want to get the same result (modulo nondeterministic aspects of it) each time you evaluate it. To comply with this, each box should return new-allocated data for further processing (and not any reference to some data stored somewhere else).
Lisp itself is a pretty permissive functional language, and actually a lot of built-in primitives are not “pure” functions. The “inside” accessor mentioned in your previous posts (as well as all slot-accessor functions) returns the data that is inside an OM container (not a copy of it): If you take it and modify it, the original container will get modified as well.
To avoid this OM provides wrapper functions such as get-chords, etc., which perform copies of inside and return the elements “inside” an object.
The clone function just avoids any mess by copying the data coming out of a box. It should be used carefully because copies are sometimes costly, but is sometimes necessary.
Hi there! Just to complement a little bit Karim’s point and the overall discussion:
As you know, all OM is written in Lisp, and (almost) all Lisp can be brought graphic into an OM visual patch. Not all is completely straightforward though
OM patches represent functional expressions, which to be consistent should have no side effect: you want to get the same result (modulo nondeterministic aspects of it) each time you evaluate it. To comply with this, each box should return new-allocated data for further processing (and not any reference to some data stored somewhere else).
Lisp itself is a pretty permissive functional language, and actually a lot of built-in primitives are not “pure” functions. The “inside” accessor mentioned in your previous posts (as well as all slot-accessor functions) returns the data that is inside an OM container (not a copy of it): If you take it and modify it, the original container will get modified as well.
To avoid this OM provides wrapper functions such as get-chords, etc., which perform copies of inside and return the elements “inside” an object.
The clone function just avoids any mess by copying the data coming out of a box. It should be used carefully because copies are sometimes costly, but is sometimes necessary.
— update: I just noticed that get-measures does not perform a copy, but I believe it should !
Thank you Jean !
Bye
N.
P.S. Now we need another ‘inside’ class to access the semantics in the container of your complement (Just kidding:)
Hi all you lispy loving folks,
Thank you Jean for your enlightenment. By the way for those you don;t know yet, Jean IS the OM guy ! so everything he states is authority !
I just want to add something for we non-specialists, and try to explain the clone issues. First of all it has nothing to do with a star wars episode (unfortunately, … . Ok , now for we non-programers, let it be known, that in Common Lisp you have (among other things) two kinf of functions. Destructive and non-destructive. Most of the last ones are in OM, so tehy don’t mess up things (cf. Jean’s post). But sometuimes, it is so practical to use teh destructive feature. So what is a destructive function. It is one that will CHANGE the object, list, etc… that it calls (ie connected to in oM). So clone function will prevent this by copying the object connected to and doing "things ion the copy and NOT on the original. This is braidly what clone does.
Hope this was somehow clear. …
So after inspection, Jimmie is right, you can do without the clone thing in the patch voice2voices. None of the function AFTER clone is destructive. It was just there because it was adapted from a lisp written method i wrote that was mostly destructive…
BEst
Good Oming and lisping…
K
Hi Karim, thank you very much for your explanations!
Indeed, my OMing is suddenly turning into a humming(!) :
Maybe it’s just for me, but I can’t think of an example where a function placed after an object would alter the latter retrospectively in a given logic? Or maybe it happened in my programming and I wasn’t aware of it (or didn’t understand it this way)… Would you have a quick example at hand?
Many thanks again,
Jimmie
Here is a simple (?) example (see attached).
SORT is a “destructive” function: it modifies (sorts) in place the input list. Calling it after inside modifies the order of internal lists in the chord-seq (without notifying/updating the editor and the box display!). The contents of the chord-seq box will therefore not be the same before and after calling sort (see other chord-seq box on the left).
Again many thanx for Dr. Jean … (thinking about the great Dr. John that maybe some of you guys, and some of you gals know)…
One very simple example i may add, for lispers :
The setf macro. very destructive. And again very simple :
Let’s take toto as a variable. We can assign a list to toto like this :
(setf toto '(1 2 3 4))
if evaluated, this expression will return :
OM > (1 2 3 4)
Now just evaluate toto :
toto
OM > (1 2 3 4)
Now let’s use something funny, the pop macro. Just like popcorn it will remove (pop) the first elmt of any list (the car of a list). So :
(pop toto)
will return the “popped” elemt
OM > 1
Now let us “inspect” toto by just evaluating toto. this will give us :
OM > (2 3 4)
So toto changed. It was popped ! [you can repeat the pop as long as you want)…
This could illustrate a destructive proceedure in CommonLisp.
Hope this was fun and not too boring for you guys and gals !
Goodnite, and may the Lisp be with you!
K
One of my Dr John’s favorite is a version of It Don’t Mean A Thing If It Ain’t Got That Swing by Duke Ellington.
And that’s the thing you’re bringing both Of you ! Some kind of SWING !
And as Spinoza once said there are 3 kind of knowledge :
1st genre : the knowledge of EFFECTS.
2nd genre : the knowledged of CAUSES.
3rd genre : the Beatitude !!
Good night and thank you !
N.
Ok, wow. thank you, this is good to know!
Here is an ‘empirical’ test I’ve just done, since I didn’t know about the ‘sort’ function. Yet, I already knew sort-list, so I tried both, and you can see in the attached image that while ‘sort’ is destructive, as already said, sort-list is not (what you have in the two bottom chord-seqs are the direct results of the sorting functions, showing that even if sorting is performed in that direction, only ‘sort’ is destructive retrospectively).
Maybe it’s an example of something that has already been said, that is: that most OM functions have been made to prevent from ‘destructiveness’? It’s a nice attention in any case
I learned something today about it, thank you!
Jimmie
Yes: sort-list is basically a non-destructive version of sort, which copies the list (but not its individual elements) before to operate (+ has an option to sort the list recursively).
Hi Karim,
Now let’s use something funny, the pop macro. Just like popcorn it will remove (pop) the first elmt of any list (the car of a list). So :
(pop toto)
will return the “popped” elemt
OM > 1
Now let us “inspect” toto by just evaluating toto. this will give us :
OM > (2 3 4)I’ve applied your ‘appetizer’ example and I’ve noticed that the evaluation of toto after ‘popcorning’ it do not echo OM > (2 3 4)
In fact, toto is becoming (pop toto)… cf. img caps
N.
Dear Nadir,
yes that’s the point. If you pop it all the way you will end up with nil .
So just replay it once in this sequence :
ADDENDUM ,
…
Don’t use the mini listener.
Do the following here :
select new from file (menu file of the listener)
you will have a text file.
type as a first line :
(in-package :om)
save your file as xxx.lisp , or whatever .lisp
Then type your code, and do your evals in .lisp file. It could be that the mini “evaluator” in the listener re-initiazlizes itself. Dont know, i don’t use it …
Dear all,
A quick question! How to extract the indicated measures from one voice object to another? For instance, there are 100 measured voice object, and I would like to take measures 30-45 to another one, and how am I suppoesed to do? Would be really appreciated if anyone could help me out!
Thanks!
Hi eksan0318
You will find in the same here (here) one self explanatory patch (that i am again attaching here).
You just have to give a list from (30 45) -1 since, the first measure is considered as pos 0 and NOT 1.
You can use for instance (arithm-ser 29 44 1) => (29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44)
then feed it to posn-match (cf. attached patch)
Best
K
voice-and-voices.omp (31.9 KB)
Hi. I beleive i fixed #'select to take care of the offsets of the included measure (april 2017, commit e2010c144). If it still screws up offsets upon playback please send me a note.
If it is ok now, you can just use the #'select function on your 100-measure voice, and pass it 29 and 44 (zero-indexed positions), and it will output a new voice containing measures 30-45. Check attached screen-shot.
-anders
Thank you both Karim and Anders!
And Anders, thanks for your tip of select function, it works perfectly!
A quick question to Karim, when I tried to download your attachments there is only a page of codes, no downloading process, how this problem can be solved? I have tried it several times still the same issue has came up.
