Mutable - Any chance Grids will be converted?


#18

i'll add the release time and format control when i get time.

btw: one misunderstanding in the above thread is how warps works...
basically its got an algorithm parameter, this changes what warps does ... so basically you should be able to use wrps object to also do the vocoding and it has more functionality (like the MI modules)

on wrps - i think then density is timbre (i suspect MI changed the name on the front panel, but didnt bother changing the code), and drive 1/2, (i assume without checking the code) are the levels for in 1 and 2... given thats what the warps panel has.

the best way to get an understanding of the usage of MI modules is to go take a look at he MI manuals for the modules, usually Ive just coded up a 1:1 mapping , but as above sometimes MI has changed the 'labels' on the front panel ... compared to the code (and I've used the names in the code)


#19

@Blindsmyth , sync libraries time - Ive added formant shift and release to the vocoder


#20

This is really great opens up a lot more expression in the module.

So Ideally we would have only one axoloti object and a possibitly to change algorithms on the object like with the original module? That would be terriffic!


#21

That is what the wrps object should already do


#22

Ah nice. But somehow I can't get the wrps to work:
Creating directory on sdcard : /Microtonal Vocoder
Done creating directory
Changing working directory on sdcard : /Microtonal Vocoder
Done changing working directory
Start compiling patch
Compiling patch... with /Applications/Axoloti.app/Contents/Java/firmware
BDIR = /Users/Simon/Documents/axoloti/build
FIRMWARE = .
RM
APP
! /Users/Simon/Documents/axoloti/build/xpatch.h.gch
. /Users/Simon/Documents/axoloti/axoloti-factory/objects/osc/brds/brds_analog.h
. ./axoloti_mi.h
LINK
/Users/Simon/Documents/axoloti/build/xpatch.o: In function rootc::Init()':
xpatch.cpp:(.text._ZN5rootc4InitEv[_ZN5rootc4InitEv]+0xa48): undefined reference to
warps::Modulator::Init(float)'
/Users/Simon/Documents/axoloti/build/xpatch.o: In function rootc::dsp()':
xpatch.cpp:(.text._ZN5rootc3dspEv[_ZN5rootc3dspEv]+0xd1e): undefined reference to
warps::Modulator::Process(warps::ShortFrame*, warps::ShortFrame*, unsigned int)'
collect2: error: ld returned 1 exit status
make: *** [/Users/Simon/Documents/axoloti/build/xpatch.bin] Error 1
shell task failed, exit value: 2
Compiling patch failed ( /Users/Simon/Documents/axoloti/Usa/Microtonal Vocoder.axp )


#23

ah, yeah, I remember now, there was a small bug in the firmware makefile which meant the warps objects weren't included in the firmware... actually theres a note in the Wrps object description, which says in will not work, and will fail to link.

you could build a custom firmware, but probably not worth it :wink:

if you do, remember to reset it , when the next version of axoloti is released otherwise you'll get really weird errors which will confuse everyone :slight_smile:


#24

I'm totally not capable of doing so but thanks for the tip! I'm pretty happy with the vocoder though, looking forward to using it in a performance next week.


#25

i'd like to see especially the alternative euclidean mode of grids ported :slight_smile:


#26

There are already Euclidean sequencer objects in the user library. They all work in the same way, so there would be no real mileage in porting Grids’ particular implementation.

a|x


#27

ah,thx! good to know! i'll receive mine in the next few days. cant wait!


#28

sorry for my n00bness but i can't grasp how those euclidean seq's work. tried different ones. do i need a counter or a steady clock (square lfo or midi clock) is enough? if someone can provide a bit of a more in depth explanation i'd be very grateful :slight_smile:


#29

ok i managed to grasp that i need a counter. now another problem: to replicate Grids or other Euclidean Sequencers you have to have realtime control over parameters. INT values on objects are not mappable to midi cc. i tried to add inlets and modify them (Sputnki sequencers) via scaling but something went wrong and i crashed axoloti patcher :slight_smile:


#30

sorry for flooding this thread but... as far as i understand it, up until now there isn't any of the available objects that really replicates the features of a realtime handy euclidean sequencer. the beauty of something simple like Grids'euclidean mode is that you can fiddle with the length of the phrase and with the fill (how many steps are filled, something called "notes" in Sputnki's versions) , all realtime. as far as i know now this is impossible using the euclidean objects as they are, also given that the length has to be always linked to the count max in the counter you use (am i right on this?)
i tried using an integer dial to both control euclidean length and counter max count. it somehow works, but really somehow... not at all as grids works, for example. am i missing something? also, when notes > length the sequencer stops, i even tried to expose notes as an inlet, connect a dial and scale it...somehow it doesn't work as it should. can someone please point me in the right direction?
(btw i think that the grids euclidean code is one of the easiest to port, i took a look at it, but i'm very far to be able to do that :smiley: )


#31

Any updates on porting Grids to Axoloti? This guy got it working on a Teensy, and shared his code:

https://kbob.github.io/2016/06/27/i-made-this-drum-machine


#32

This guy got Grids working on Arduino and shared his code:

http://www.goltstein.nl/MIdrum_english


#33

so unlike the other MI modules, it can't really be 'ported' as such, as the grids code was based on the avr chip, not arm like later modules (which were ported)

also the code was quite tightly related to the hardware clock.

that said, its actually one of the simpler modules really (code wise), so basically, you can just take some of the MI code and adapt it fairly easily e.g. to take a clock input as a input.

but with so many projects on the go, never had a chance to take it further... but im a bit more familiar with the code base now, after playing with it on the Organelle a bit.


#34

But the Organelle is an ARM-based computer (a ridiculously expensive one with some knobs and buttons and a tiny screen), right?

I just got an Axoloti and was hoping to be able to build a cool drum box with it. Perhaps I will need to sell it and get an Organelle instead...


#35

no, Organelle is a linux based running pure data, a very different animal from Axoloti.
(I actually like both, for very different reasons)

the history of grids for the organelle is:
a guy created a Max/MSP external based on the MI code, and then another guy ported that external to pure data, which then was built on ARM and so the Organelle.

this is the great thing about open source, anyone can do it, assuming they have the time and skills. there is nothing stopping anyone here doing the same thing for Axoloti....
(they could use either that external or the original MI source code as a starting point)

if you dont have the C++ skills to do this,

then you could always try to patch something similar, there are quite a lot of sequencing options already available in the community library, and you can create your own too.


#36

Thanks very much for the lesson; fascinating stuff. Coding a Grids or its equivalent is not in my bailiwick. I don't see how you could build an equivalent from sequencers, given that Grids is a generative device created from AI training on a corpus of existing grooves. That seems far beyond simply patching some sequencers together.

Perhaps I will try to recreate the Teensy build I linked above. If the code is plug-and-play I might be able to pull it off....


#37

maybe a good starting point might be porting the euclidean alternative mode of grids, as i pointed out above, which is much easier code-wise than the drummer mode.