That is what the wrps object should already do
Mutable - Any chance Grids will be converted?
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()':
warps::Modulator::Init(float)'
xpatch.cpp:(.text._ZN5rootc4InitEv[_ZN5rootc4InitEv]+0xa48): undefined reference to
/Users/Simon/Documents/axoloti/build/xpatch.o: In function rootc::dsp()':
warps::Modulator::Process(warps::ShortFrame*, warps::ShortFrame*, unsigned int)'
xpatch.cpp:(.text._ZN5rootc3dspEv[_ZN5rootc3dspEv]+0xd1e): undefined reference to
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 )
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
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
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.
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
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
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
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 )
Any updates on porting Grids to Axoloti? This guy got it working on a Teensy, and shared his code:
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.
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...
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.
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....
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.
I’d just use the grids pure data external source code as a starting point, it’s actually pretty close to what required by Axoloti.
( you’ll find the Pd source in my MI4PD repo)
Well to be honest, personally I gave up grids and just made my own Euclidean seq and havent looked back ever since. I played a lot with Grids for VCV rack, and to be honest after plaing alot with it over there, I realised it wasnt that nice anyway.
Grids is more than just a Euclidean sequencer... its more like a pattern bank, with a huge number of patterns.
I do actually like it quite a bit, but probably because Im not really into (nor good at) drum programming, so nice to have something that comes up with some nice rhythms