hello all,
I dare to suggest a new feature for om7 after the positive feedback I received in the list. not wanting to annoy anyone but just setting the ground for comments and discussion. I’m not sure if it’s possible but here it goes: how about user-setting the x-step in editors? how about setting non-uniform grids? I mean with different values. I thought of this as I sometimes use uneven divisions of a beat (haha as a user-defined ‘swing’ or ‘notes inégales’). and that kind of grid would be of great help.
I would like to add another one, related to the previous one: quantisation for chord-seqs. I already did some programming for it but in an inelegant way although it serves its purpose for now. but having a finer detail in quantising would be also great. when I use random-driven generation for time distribution I find it hard to quantise those values and retain its character (and on top of that trying to preserve a musician friendly rhythm notation).
I know that chord-seqs are not meant to be some kind of sequencer, but I really feel more comfortable with this objects than with commercial sequencers aiming to a different kind of music.
thanks for your comments,
perti
Dear Perti,
what you suggest is perhaps similar to my quantization-method which is part of my personal Library „OM-Carlo“. Its not documented yet, but I made a simple example (see PDF-Link) for you to demonstrate the concept (musician friendly rhythmic notation):
- Define a “Quant-Space” (Bars with different tempi, divs, beats…)
- Adjust at one or different Quant-Level (inside the Chord-seq-Object)
- Transform to a Voice-Object or Export via MusicXML
Have a look and tell me if its corresponding…
Regards
Wolfgang
demo-rhy-patch.pdf (2.7 MB)
hello wolf66,
this is roughly the same I was thinking of. just a bit more complex but full of possibilities. nice work! is that library available, or going to be at some point? please keep us posted.
one of the things I was concerned about in quantising chordseqs is because it seems I cannot understand the voice and poly objects well enough, what I get from those is different of what I get when exporting (to midi or whatever). so I feel more confident with chordseqs and multis. and these seem more easily editable. at the moment I’m using a ‘best-match-from-list’ function, which takes a list of onsets (and/or durs) and ‘corrects’ each one to a list of candidates, for placing them into a ‘notationally readable’ grid. maybe it’s not elegant programming but fittes my needs up to now.
please let us know about OM-Carlo, seems very very promising! I volunteer to beta-test.
thank you again Wolfgang,
perti
Dear Perti,
generally the quantization topic is very complex and needs a lot of user-specific knowledge about good musical notation. I agree that the chord-seq object is the best place to work on rhythms anyway. because you can handle things more feely and intuitiv. Hopefully the OM7 version of the chord-seq object stays pure und simple (without too much extras).
At the moment I’m not planning to share my library, but thanks anyway for your offer to be a volunteer beta tester!
Regards
Wolfgang
Bonjour,
Concernant la future version d’OM7, je remarque que dans sa version beta. o.2, le cercle a disparu alors qu’il était dans la première bêta dans le dossier Math et qui n’est plus présent aussi. Est-ce provisoire, tout comme l’absence des outils d’analyse MathTools des groupes ZN - notamment transp-comb bien utile pour les multiplications d’accords et Transp - DN avec notamment PC-Set et P-Form utiles pour identifier des accords ou des agrégats selon la classification de Forte et l*'IC-Vecto*r - ainsi que le groupe Aff ? Même question sur les deux classes Text-View et Text-Box bien pratique dans un patch interne pour vérifier des résultats ?
Salut Didier,
pour OM# la dernière version date de Janvier 2020 sur le GitHub de Jean Bresson ( v1.0) ici.
il y a une librairie mathtools ou on retrouve ce qu’il y a dans OM ici
pour le display de texte, il faut faire cela avec [textbuffer]
Best,
Jerome
PS : il y a un salon om-sharp sur le site de discussion, ce serait l’endroit le plus approprié et le plus susceptible d’attirer l’attention de Jean @bresson
il y a une version de Combine ici
Tips : il faut renommer les dossier en effaçant les “-master” , par exemple combine-master deviendra combine. Idem pour mathtools sinon cela ne fonctionne pas
Cher Didier,
om7 n’existe pas. Il s’appelle desormais omsharp, un projet sous la direction de Jean Bresson. Par contre openmusic est toujours en developement et vous trouverez tous les outils encore disponibles. Je vous invite donc si vous le voulez, de telecharger al derniere version om 6.17
Bien a vous
K
Salut Jerome, merci pour ta réponse. J’avais quelque peu délaissé OM7 et je n’avais pas vu la toute dernière version OM-Sharp. Donc merci pour les liens pour le télécharger ainsi que les librairies Combine et MathTools. J’ai téléchargé aussi OMPitchField et OMTristan. Je les ai installées et Combine, MathTools et OMPitchField sont reconnues - sur le PC je n’ai pas eu besoin de renommer les dossiers et je vais voir sur le Mac - en revanche OM Tristan n’est pas reconnu. Donc qu’entends par effacer les “master”, ça n’apparaît pas dans les noms de dossiers ?
Si ça n’apparait pas, c’est que tu as télécharger les releases, tant mieux !
mais tu peux être amené a télécharger un repository, et là, il y aura les “-master”.
Pour les librairies, il faut que tu prennes des versions compatibles om# toutes les librairies ne fonctionnent pas sur om#
Dans une librairie, il faut voir si un fichier “nom-de-la-librairie.omlib” existe, alors la librairie est sensé tourner sur om#
Il faut garder a l’esprit que om6 et om# ne sont pas les mêmes applications.
Cher Karim, merci pour votre réponse rapide. Comme je l’indiquais à Jérôme, je n’avais pas fait attention à l’évolution de OM7 devenu OM-Sharp. En revanche, j’avais bien suivi celle d’OM et je suis bien sur OM 6.17.
Pour revenir à OM-Sharp, je me heurte à un problème d’évaluation dans l’éditeur Lisp (Listener - System int/out) ouvert dans la double fenêtre avec le raccourci CTRL/Shift L (avec dans Préférences Enable Listener Input coché). Quand j’évalue avec CTRL E, comme dans l’éditeur Lisp d’OM 6.17, rien ne se passe sinon l’indication Emacs Command CTRL+E qui s’affiche en bas de la fenêtre.
Où se situe mon erreur ?
Bien à vous.
Didier
Cher Didier,
Je suis desole de ne pas pouvoir vous aider sur om-sharp (je ne m’occupe que de openmusic). Mais a priori, il s’agit juste d’erreur de commande. Il faudrait pour cela demander a Jean, quel raccourci il faut faire pour l’evaluation d’une expression dans ce cas precis. Il te repondra certainement. Par contre je ne sais pas si il consulte toujours cette liste, car il en a cree une pour om-sharp comme Jerome l’a indique. C’est ici:
Amities
K
Cher Karim, merci pour la réponse et le rappel du lien du forum pour le support de OM-Sharp. Mais j’ai trouvé, tant pour le Mac et le PC. En fait, je l’indique ici au cas où, mais en plus de cocher dans Preferences Enable Listener Input, Handle Error Messages et Print System Outputs, il faut cocher Auto ev-once et là avec un simple “Return” l’évaluation est effective.
Amitiés.
Didier
Merci Didier pour l’info.
amities
K
Bonjour Didier,
En principe il suffit de cocher “Enable Listener Input” pou activer dans le cadre du haut l’interface du REPL (“Read-Eval-Print Loop”) de Lisp. Il faut ensuite simplement valider des commandes avec “Return”.
“Handle Error Messages” concerne les erreurs qui peuvent se produire en évaluant un patch, tout comme le mode auto-ev-once. Ces options ne sont donc pas liées en principe.
a bientôt
Jean
Merci Jean pour ces précisions. Je découvre OM7 devenu OM-Sharp et j’apprécie beaucoup sa nouvelle présentation graphique très agréable, “très classe”. Très appréciable aussi la conversion de nos anciens fichiers OM dans OM-#. Au début, j’ai été surpris par la décomposition en “sub-patchs” de l’Om-Loop mais au final c’est très bien et très pédagogique avec l’apport pour vérifier les résultats des “pop & connect value”.
Merci pour ces remarques, qui sont toujours bienvenues!
Pour être plus précis, les OMLoops ne se décomposent pas, mais deviennent simplement des (sub-)patches comme les autres (il n’y a pas de niveau de “décomposition” supplémentaire). Il me semble que c’est plus simple, car n’importe quel patch peut devenir un loop, dès lors qu’il contient une boîte iterate.
A bientôt