Home made sequencer in Max

[bronswerk]

Bronswerk, dat ziet er strak uit!

De GUI getoond in de twee plaatjes, is dat native Max/Msp? Hoe heb je dat aangepakt?

Yep, als je het idee hebt dat max/msp er uitziet als blokjes met daar tussen lijntjes, klopt ook,
maar sind max/msp versie 5 is er de mogelijk voor 2 soorten weergave nl de
"patch" weergave = blokjes en lijntjes en de
"presentation" weergave = zie bovenstaande plaatjes.

dus standaard max/msp.

 

[robnet]

Yep, als je het idee hebt dat max/msp er uitziet als blokjes met daar tussen lijntjes, klopt ook,
maar sind max/msp versie 5 is er de mogelijk voor 2 soorten weergave nl de
"patch" weergave = blokjes en lijntjes en de
"presentation" weergave = zie bovenstaande plaatjes.

dus standaard max/msp.

Ok, dank je.

Wat betreft het quantizeren, bedoel je dat je geen midi clock hebt waaraan je de binnenkomende midi events kunt quantizeren? Is er geen referentie clock?

 

[bronswerk]

Ok, dank je.

Wat betreft het quantizeren, bedoel je dat je geen midi clock hebt waaraan je de binnenkomende midi events kunt quantizeren? Is er geen referentie clock?

Jazeker wel, zonder clock geen programma! In de eerste versie had ik verschillende clocks elk met hun eigen clockspeed. Er was een masterclock die pulsen uitstuurde van 48x per tel en van deze clock werden subclocks aangestuurd van bv 4x per tel en zelfs 1x per tel (je wilt nl dat het starten en stoppen van sequences ook gequantiseerd wordt, anders wordt het alsnog een rammelend geheel)

Quantizeren is niet zo gemakkelijk, wat doe je nl als een event te vroeg OF te laat is? In beide gevallen wil je op hetzelde tijdstip uitkomen. Normaal gesproken wordt in dit soort situaties gebruikt gemaakt van een "delta time" event lijst. In deze lijst staan de events geregistreerd waarin het verschil tussen 2 opeenvolgende midi events wordt bijgehouden, dus bv hoe lang het duurt tussen een note-on en de daaropvolgende note-off OF een nieuwe note-on, dat kan natuurlijk ook. Die delta time is een getal in milliseconden. Dus het programma weet hoe lang het duurt voordat het volgende event moet plaats vinden. Die delta time wordt dus gequantiseerd dmv een simpele formule en afhankelijk van je tempo. Bij het inspelen van akkoorden is die delta time natuurlijk heel kort.

 

[robnet]

Quantizeren is niet zo gemakkelijk, wat doe je nl als een event te vroeg OF te laat is? In beide gevallen wil je op hetzelde tijdstip uitkomen.

Even zien, nooit hard over nagedacht. Ik vermoed dat er twee benaderingen zijn.

In het eerste geval laat je de inkomende midi events ongequantized horen in real-time, en pas je quantizing pas toe in de daarop volgende loops van de sequence.

In het tweede geval, als je dus inkomende midi events altijd quantized (qua timing) wil horen, en zowel te vroege als te late noten wil quantizen naar dezelfde plek in tijd, dan zul je een delay moeten inbouwen van een halve quantize unit (effe op gevoel), alle input verzamelen maar niet laten horen, en de zaak dan gequantized afspelen.

Zoiets?

 

[bronswerk]

In het eerste geval laat je de inkomende midi events ongequantized horen in real-time, en pas je quantizing pas toe in de daarop volgende loops van de sequence.

Bingo.

In het tweede geval, als je dus inkomende midi events altijd quantized (qua timing) wil horen, en zowel te vroege als te late noten wil quantizen naar dezelfde plek in tijd, dan zul je een delay moeten inbouwen van een halve quantize unit (effe op gevoel), alle input verzamelen maar niet laten horen, en de zaak dan gequantized afspelen.

Heb je gelijk in, maar als user wordt je dan geconfronteerd met een aanzienlijke delay en je kan dan heel gemakkelijk de draad kwijt raken.

Optie 1 is de beste optie en in de praktijk werkt het gewoon.

 

[L56]

Het dilemma van hoe sla ik events op heb ik ook gehad toen ik met het Maximum Midi boek ooit heb getracht een sequencertje te bouwen. Ging goed, maar ik liep stuk op een bruikbare GUI. Anyway, ik kwam toen op losse event uit, maar wat als twee keer de zelfde note on langs kwam, voordat een noteoff was geweest (niet ondenkbaar als je opneemt met 2 controllers aaarrgh

Anyway, wil je de patronen wel gequantized opslaan? Ik heb juist liever de rauwe data gesaved en dat de instellingen van het programma de quantalizing (sic: gast op youtube) bepaald. Zo kun je achteraf (na opslaan en weer inladen) tenminste nog dingen veranderen. Dus Scenes + die 32 eventfiles (zo noem ik het maar even) gecombineerd is hoe je het hebt achtergelaten.

Als je het wilt exporteren om ergens anders te gebruiken/uitwerken, ja dan wil je dat alle settings wel *kunnen* worden meegenomen.

Qua drumpartijen: geen lagen, maar zou het mogelijk zijn om de data uit een x aantal slots te mergen naar 1 slot?

Mocht je nog ergens hulp bij nodig hebben ofzo, dan laat maar horen.

 

[bronswerk]

Het quantiseren was non-destructive, dus tijdens playback werd continu de gequantiseerde waarde berekent. Dit was zoals versie 1 iig werkte. Opslaan op de harde schijf was toen nog een stap te ver.

In versie 2 ben ik er nog niet helemaal over uit welke route te volgen. Ik ben zojuist tegen een aantal freeware max/msp objecten (ajm serie) aangelopen waar ik waarschijnlijk wel wat mee kan. Een interessant object is een clock die timing posities uitstuurt afhangkelijk van de gekozen quantisering (bv q=16) zo dat dan per maat (in 4/4) 16 timing posities er uitrollen zoals:
1.1.0
1.1.120
1.1.240
1.1.360
1.2.0
1.2.120
enz.

Quantisering op 16den is nogal grof voor recording, maar een klok die werkt op 32sten of 64sten geeft alweer een heel ander beeld. Het voordeel van deze methode is dat events met een absolute tijd gedefineert kunnen worden (ipv de delta time zoals hierboven besproken) en dat zaken zoals veranderen van tempo achteraf geen problemen hoeven te geven, zoals dat in versie 1 wel het geval was.

Ik hoef niet die nauwkeurigheid te hebben zoals een Logic of Cubase. Het snel neerleggen van sequences en loopen is de hoofdzaak.

Qua drumpartijen: geen lagen, maar zou het mogelijk zijn om de data uit een x aantal slots te mergen naar 1 slot?

Dat ging dus niet ivm delta time (tenzij je in realtime alle data naar 1 slot zou routen en recorden). Ik wil eerst die nieuwe objecten uitproberen en kijken wat de mogelijkheden zijn. Staat op mijn verlanglijstje, maar al met al is het best wel een ambitieus project en de basis moet eerst in orde zijn.

 

[robnet]

Ik zit er misschien helemaal naast, wat betreft jouw behoeften voor quantizeren, maar zover ik weet kan in Max/Msp 5 de standaard millesec clock nu ook met musical values (noot waarden) werken. Die ajm modules zijn misschien gemaakt voor een vorige versie van Max?

 

[bronswerk]

Ik zit er misschien helemaal naast, wat betreft jouw behoeften voor quantizeren, maar zover ik weet kan in Max/Msp 5 de standaard millesec clock nu ook met musical values (noot waarden) werken. Die ajm modules zijn misschien gemaakt voor een vorige versie van Max?

Klopt, maar er zitten wat handige features op die niet standaard in max zitten. Die ajm modules geven een frisse kijk hoe je met clocks kunt omgaan, bv starten op een beat of bar of op een van te voren gefinieerd timepoint (bv 4.1.0). Maar het grootste voordeel wat ik zie is dat op een bepaald trigger tijdstip een noot x met velocity y wordt uitgestuurd met een lengte/tijdsduur van bijvoorbeeld 2 beats. En die tijdsduur kan achteraf gemanipuleerd worden. Dus van legato naar staccato...

Quantizeren is beslist noodzakelijk anders valt het systeem in duigen, dat merk je gelijk als je een paar sequences laat loopen zonder quantizering, de mate waarin laat ik vrij, varieert van 1/32 tot 1/1. Ook de lengte van een totale loop moet gequantiseerd worden (in beats iig) anders gaan de sequences uit de pas lopen, ok leuk voor experimenten.
(wat betreft die looplengte, je zou ervan uit kunnen gaan dat wat je opneemt een onbepaalde lengte heeft en dat je om de zoveel beats een nieuwe startpuls geeft, maar dan moet je van tevoren opgeven hoelang die looplengte in beats is, mijn opzet is dubbel nl of automatisch of handmatig. Automatisch wil zeggen wanneer je de recording start en weer stopt dat dan die lengte in beats de looplengte is; handmatig is getalletje opgeven in desbetreffende slot)


Het probleem van opnemen van noten is HOELANG een noot duurt. Worden de note-on's en note-off's als aparte events beschouwd OF beschouw je het als een note-on met een BEPAALDE TIJDSDUUR? Die laatse benadering is lastiger, stel een note-on komt op tijdstip x voorbij. Dit wordt opgeslagen als een event in een lijst. Nu komt er een note-off voorbij op tijdstip y. Nu moet ik terug gaan zoeken waar de originele note-on was opgeslagen zodat ik dat event kan gaan bijwerken met de "duration" (is lengte noot) van die noot. Het eerste event was eigenlijk nog niet afgesloten omdat er toen nog geen note-off was. Toch is deze manier de betere omdat het veel meer mogelijkheden biedt om achteraf in te grijpen. Max heeft trouwens een tool om dit probleem op te lossen. Alleen deze tool werkt met geindexeerde events dus eerste event heeft index 1, tweede event index 2 enz. en werkt dus niet met absolute tijdcode, mijn taak om die twee te verenigen, want die tijdcode heeft absoluut voordelen. Oh ja, die tijdcode moet werken per slot dus als ik 2x zo snel die tijdcode uitstuur, wordt die sequence 2x zo snel afgespeelt bv.

 

[bronswerk]

inmiddels een week verder...
heb de basis voor opnemen en weergeven van een sequence staan
probleem was het opnemen van akkoorden dwz meerdere midi note-on's op hetzelfde moment maar is uiteindelijk toch opgelost
ik was aangenaam verrast dat overdubbing nu heel eenvouding gaat in loopmode
het opnemen van drumpartijen wordt nu een stuk makkelijker in tegenstelling tot versie 1

een plaatje hoe het er voorlopig uit ziet, met wat begeleidende tekst. (met dank aan de max helpfiles)

 

[bronswerk]

en alweer een maand verder.....
gezien de toch wel behoorlijke complexiteit van het programma was het ondoenlijk
om alles in standaard max te realiseren
daarom besloten om een groot gedeelte qua besturing in javascript te schrijven
dit werkt lekker en houdt het aantal objecten in max minimaal
wordt vervolgd..

 

[L56]

java bovenop max...is het dan nog een beetje werkbaar qua snelheid? Is het dan niet verstandig om het geheel te porten naar 1 andere taal.

Zo is er een midilib die vrij simpel werkt in C#, maar weer als nadeel heeft dat je niet realtime noten kunt plaatsen terwijl de library speelt (Ben ik aan het proberen te fixen) en maar 1 midi port ondersteund (baal ik stevig van en ga ik ook proberen aan te pakken).

Als het werkt, moet je ermee doorgaan natuurlijk, maar het is duidelijk dat de limeit van bruikbaarheid van MAX in zicht is ;-)

 

[bronswerk]

java bovenop max...is het dan nog een beetje werkbaar qua snelheid? Is het dan niet verstandig om het geheel te porten naar 1 andere taal.

een javascript object is standaard aanwezig in max
in mijn programma zal alleen de afhandeling van ui controls
en wat trigger events via een javascript module gaan,
dit is ingewikkelder dan op het eerste gezicht lijkt omdat er nogal wat
randvoorwaarden zijn wanneer een slot moet gaan opnemen of weergeven
het opnemen en weergeven van midi zelf zal nog steeds op de ouderwetse "max"
manier gaan omdat cycling 74 zelf aangeeft dat tijdkritische elementen
beter niet viaeen javascript module kunnen gaan

porten naar een andere taal is hopelijk niet nodig, trouwens als ik de cpu meter
in windows mag geloven had mijn vorige versie (1) een cpu van ongeveer 8%
met alles erop en eraan
een testversie die ik een paar weken geleden had met 32 clocks running
(maar geen midi) gaf een cpu aan van plm. 4%

 

[bikkel]

Bestaat hier ook een hardware equivalent van, met die accoordherkenning?

 

[bronswerk]

Bestaat hier ook een hardware equivalent van, met die accoordherkenning?

je bedoelt een sequencer waarbij de realtime opgenomen sequences met akkoordherkenning gemanipuleerd kunnen worden?
er is er maar 1 en dat is de "Direct" sequencer van Vangelis, maar is rudimentair qua akkoordherkenning
een Octopus doet wel wat met scales maar een akkoord aanslaan en dat herkennen is er niet bij
natuurlijk is er ook nog de Karma (Oasys, M3) maar realtime opnemen zit daar dan weer niet in (en is in feite 1 grote stepsequencer).
mijn ideale sequencer lijkt een kruising tussen Direct en Karma te zijn

 

[L56]

Qy700 van yamaha

...en een hele bups arranger keyboards MAARRRRR....


het gaat het om toegangkelijkheid natuurlijk. ;-)

 

[bronswerk]

ok, deze draad maar eens nieuw leven inblazen

ik heb 2 Youtube video's gemaakt met mijn Max patch, 1 demootje kwam een tijdje geleden al langs



en

 

[L56]

Bij toeval net weer over deze draad gestruikeld. Ik vind het prachtig wat je hebt gepresteerd!

Ik heb ondertussen zitten zoeken naar een realtime "arranger" voor mac of pc, maar niet veel soeps gevonden. Dit lijkt me echt de bom. Je hebt volgens mij nagenoeg geen concurrentie. Ga zo door! ;-)

 

[Ramirez]

Ben je inmiddels al wat verder gekomen,ben namelijk erg benieuwd.
Zoals l56 al zei,er is nog niets zoals dit op de markt,dus je zou de eerste zijn.
'T ziet er echt geweldig uit.

 

[bronswerk]

Ben toch wel een stuk verder gekomen.

- scenes fucntionaliteit toegevoegd
- complete songs kunnen gesaved worden
- eigen akkoord herkenning geschreven (ipv afhankelijk van een third-party object)
- sync mogelijk via midi clock
- compleet nieuwe UI

Ik had trouwens een tijdje geleden een nieuw stukje geupload op Youtube.
Ditmaal een klassiek stukje. Er wordt gebruik gemaakt van 4 korte sequences, meer niet.



Voo geinteresseerden is er op het KVR forum meer info te vinden over Improvisor.