The future of Axoloti?

#1

Hi Guys,

I've just finished the racked version of my Axoloti, now it runs smoothly in my studio.
Last evening tried a few patches, old noodles, etc., and actually came across my old problem with the platform, that I almost forgot : (for me) it seems, if you're not a regular forum member, you're kinda' lost.

The patching software is a bit outdated, can't really see any progress there, yet, there is a lot of potential in it, like better graphics, more stable operation, etc.
It is unbelievable that I can't double click on a patch to load it into the patcher software. Maybe it is just me and my system, I don't know, but it is really frustrating.

My other problem is the "jungle" of patches, sub patches, modules, user modules, libraries, etc. I mean, again, maybe it's just me, but I just need something more ... how to say it in a polite way, easy to use, maybe?

In my studio, I also have a MicroModular and honestly, the Axoloti is MUCH more powerful than that little box, but, far more hard to use. I mean, on Mac, even with a WineBottled editor, it is far more stable than the modern Axoloti.

Don't get me wrong, I love this thing. It has given me so much fun-time, but compared to other things in my studio, it is not really user friendly...hah, actually, that is the expression I was looking for : Axoloti has to be more user friendly.
I don't know, maybe the creator of the project could involve others into the development of the patcher, I don't really know, I'm not an expert.

Just another thing comes in mind right now is the sub-patcher - patcher thing...I know, you can copy the sub-patchers into your folder and you can point the software's search path to the folder, yet, you can't really create single file patches...I mean, for me, and again, forgive me, I do not want to be rude, but the whole thing is sooooo nerdy, it is literally a jungle, sometimes, a mess to handle.

I am pretty sure, this could be a true replacement of the Nord, but now, it is "just another crazy DIY DSP thing..." and honestly, seems a bit "abandoned"?

Guys, sorry if I was emotional, but...you know, I just wanted to be honest.

#2

To be honest I think everything is scaled to what is necessary. Axoloti only has limited resources and since it is a musical instrument, to me it makes more sense that it uses its DSP power on audio related tasks, rather than a nice user interface.

BUT I do agree with you there are sooo many things that could be made better in the patcher., like simple shortcuts and so on, I agree things do stand very still for long periods of time........

I understand your frustration, the learning curve can be a bit steep. If you don't want to spend time learning and researching, you should probably go for a more "finished" instrument and not one that take a lot of effort.

But if you spend a little time going through some of the tutorials and reading a bit here and there you can go far.. And also ask a questions here and there.

But overall you won't get far, without having to learn something and dong an effort. Yes it does take time away form making music.

Regarding stability, I think Axoloti has crashed less than a handfull of times in the 3-4 years I've used it for now, so dont recognize that aspect.

Well, some of the other instruments, you PAY for a nice user interface. On Axoloti you have to build it yourself, work for it, but Axoloti is on the other hand very cheap. For example I bought all the part to make the synths I want but I have not build it yet cause I am a bit scared to break it. But I have it all and eventually... :slight_smile:

I agree development is slow. But I dont think it is abandonned, just very slow development as I think people have jobs too.

ANyway, a lot of the issues you are having will be sorted out over time, if you make an effort of course :slight_smile:

#3

:smiley:
You're right, I have to spend a bit more time on for sure...

#4

As mentioned I understand your frustration. When I started out with Axoloti I was very noob to DSP programming. Today, I can write almost anything I want :slight_smile: So just keep going you will get there :slight_smile:

And use the forum search function. It can be a bit messy at times, but there is a lot of relevant information to get there. :slight_smile:

#5

can understand your frustration entirely, you have very valid points.

a couple of thoughts...

  • standalones patch - you can embed subpatches, so this means they are a single file.

  • there has been quite a bit of development done on the next version (you can see dev activity in GitHub, as its open source), but lots of changes have meant it taken perhaps longer than wanted to stabilize it. (sorry, I do not know when its likely to be released)

  • a few other developers have been involved, but given this is voluntary, of course efforts comes and goes (*), and its notoriously difficult to get open source developers involved on relatively small projects.

as I say I agree with many of your points,
unfortunately, unless more community members step forward, and lead things like documentation and development efforts - I can't see how its going to come along any faster.
(imo, the price of axoloti means it cannot sustain more full time resources above Johannes, who is also split between support, production and development)

to finish on a more positive note;
axoloti is still under active development, and even axoloti control hardware is 'there', its just going to take a while longer.

(of course, this is all just my opinion, give what I can see... Johannes is the only one that can really answer these points)

(*) Im 'guility' of this, but that's because as a volunteer, sometimes other things/projects come up that interest me - its not that Ive abandoned axoloti, just I wander off for a while, and come back when ive more time.

#6

i don't want to offend anyone, but.
every time i see „ease of use“ talks in context of csound / supercollider / axoloti / etc. — it resembles me „why James Joyce's books are so hard to read?!“ question :sunglasses:
actually, it is the easiest platform of this kind. at least, in terms of building patches.

UPD: but if the topic is called „the future of axoloti“, what i miss in Axoloti ecosystem is some of tools/objects for multiple Axoloti boards interconnection and data exchange, because building synths made of multiple Axolotis is so tempting perspective…

#7

As I wrote a few times, my post was a "no-offense" one.
Obviously, have to dig deeper, just wanted to know, if this project is still breathing...

Again, I wrote, it should be more user friendly...I mean, I'm writing this after years of Max/MSP and my medium successes as encoderaudio :wink:

#8

Max/MSP is, after all, a commercial sofware, so the vendor obviously can put more effort in improving usability.
Axoloti is free in its software part, which is the great avdantage, but on the other hand, we often have to sacrifice something to have that advdntage.

#9

If you know Max MSP I think you will learn quickly :slight_smile:

#10

Yup, totally agree with this one.

I think all reasonable questions after so long without an update.

yeah, Max is commercial, and also is of course now linked with Ableton, so a bit of investment there too.
its probably 'fairer' to compare to Pure Data, which is shall we say 'less pretty' , and has a few bugs/quirks … but even PD has a much wider user base, so much more open source interest.

but at the end of the day, I tend to just use whatever (platform/software), I feel fits the task at the time, so I don't use Axoloti for everything, but Ive used it in enough places that its value (for me) is beyond doubt.

#11

PD has been around for more than 20 years – compare this with Axoloti )
and PD does not have dedicated hardware part, which costs money and needs some effort to be obtained.

i strongly suspect people that come from pd / csound / supercollider / etc just don't understand the power of such solution right from the start. it's not that obvious. i myself needed some time to realize that Axoloti is poor man's Kyma (which is very cool), and that Axoloti offers better audio quality (honest 24/48) than concurrent platforms, e.g. Bela, so decided to stick with Axoloti as my primary platform.

#12

Hello Snaper,
I'm the guy who answered your question regarding Audio IN/OUT connections a month ago, which was my first post/answer here and I have to admit I was somehow expecting more people to join in and help with the topic.

I did a lot of research and read tons of posts here before buying my Axoloti, and although I found hard to find certain info, I thought that some sort of manual was available.

For my surprise the most valuable assets I found, like the GPIO pins layout and a small Guide for dummies, were all made by Axoloti users.

Don't want to sound picky, since like many say the price is very low and I love it already for what it can do, but somehow a better first steps guide would be great for the "user experience" and to seduce potential buyers...

Originally seems you don't have to be a programmer to make your stuff, like with a Nord Modular, but is not the case... to make relatively simple things there are loads of math modules to be learnt, and modifying people patches is far from basic and self explainatory.

I understand a project like this has very little resources in terms of money and time, but it's a real pity since it's so powerful and versatile...

I try to read around and participate, help every time I can, maybe this way the community grows and more users participate :slight_smile:

Really hope this platform keeps evolving!
Thanks to all of the active users!!
Cheers

#13

Hi guys,

I've been involved in development on and off and am pretty familiar with the codebase. I completely agree about the workflow having some rough edges. There are some obvious things I'd like to do to make it more approachable and user friendly. A big impediment to progress is the tight coupling between the patcher and firmware code generation. A project I plan on doing eventually is to extract the code generator and turn it into a clean API. User interfaces could then be more decoupled, and power users could patch directly against the API. I'd also like to implement live patching; the current code generation / compilation approach isn't ideal for that though, we'll need a more sophisticated mechanism. I've got a few ideas there, it's just a matter of finding the time to implement it.

I haven't been able to get in touch with Johannes for a while so it's unclear what his plan is for future development. There's a bunch of newer code lingering in our experimental branch that I would like to get released. I don't think it's time to panic yet though. If it ends up seeming like development has completely stalled, I'll simply start doing separate releases, possibly under some other name so we can keep things straight in the community. There's no reason we can't have multiple "distributions" that run on the same Axoloti hardware. The hardware leaves us a lot of room for creativity. The code is all available; there's nothing stopping us from continuing development. We do need to make an effort to clean things up in order to get more developers involved though I think.

Best,
Nicolas

#14

I agree with you @urklang

I did meet with Johannes at Superbooth (so was a while a go too) and then he was still keen to get this out (and also axoloti control)

but the experimental branch has a lot of new code, including a re-write of the editor, new chibios (which also meant new midi), new code for axoloti control, and so there are/were a lot of loose ends.

I agree its a bit frustrating, theres so much good stuff in there that would be great to get out there, but now its mixed in with less finished code (afaik). unfortunately, i think the goal for the release was a bit too ambitious, so its been hard to close off - but thats easy to say in hindsight.

also I've not had time to contribute recently, as I've got many other projects on the go,
o that has not helped the situation,
and honestly these days, I've lost track of what the 'essential' tasks are that need to be done before release - so hard to know how close it is, which makes it hard for me to be motivated to help 'push it over the line'

but as you say, there is no need for panic, the code is all open source, so other variations could be released (*), or developers could help out on the experimental branch to get it finished, and ready for release.

also i will say, while 1.0.12 is not perfect, its very stable ... this was the reason experimental/next release was more ambitious, because it was felt 1.0.12 could bide us some time.
however, it was not expected to be this long, and of course I recognise, users like updates, so that it doesn't feel like its stagnating.

anyway, personally i do more development in the winter months, so lets hope we can sort something out during the winter.

(*) of course the experimental branch cannot be released, as it has code thats unfinished/buggy, thats why its not released :wink:

(*) variations, could cause other organisational issues
e.g. if object format changed, then you could not commit these to the axoloti community library, as this needs to be fixed to the officially released version.
(however, the library structure already allows for additional library sources, so thats an option)

#15

This might be a bit left field, but I have wondered whether it might be possible to for their to be a light weight version of the patcher or something that can do a similar job, that could easily run on the common SBC's we have these days, like raspberry pi's etc.. Such a project could run separately somehow, and be designed without a lot of the bells and whistles the main patcher has.
I don't know how something like this could be done, I don't have the skills, but with the plethora of SBC's out their now, this could certainly offer a lot of flexibility for users..
:grin:

#16

This is exactly the kind of thing that would be possible if the firmware code generator were completely separated from the patcher interface and driven by an API. SuperCollider has an architecture kind of like this. There is a notion of "sclang" and "scsynth" which are logically separated, client and server respectively. The server isn't aware of what kinds of user interfaces exist, it merely runs the correct DSP code in response to API calls which if I recall correctly are all packaged in Open Sound Control messages. "sclang" the standard client language is just one of many possible clients that can request DSP work on the server; there are bindings for many other languages.

So as a concrete example, given the low level API, you could just plug your Axoloti into a Raspberry Pi or similar and generate code for it from your language of choice via API bindings, say Python for example. There wouldn't be any need for Java or for the full heavyweight patcher app. And then gradually other more lightweight user interfaces could be developed. On the other hand, I think the full patcher implemented correctly could easily run on a Pi, we just have to re-evaluate some of the implementation choices. My gut feeling there is that we'd need to abandon Java completely. I've been impressed with VCV Rack's UI which is based on GLFW but there are other decent choices too. SuperCollider's IDE and UI are all built in Qt, and I'm pretty sure it's viable on a Pi.

#17

Sounds like an interesting longer term plan.
Agreed that Rack is pretty impressive as a project. To be clear, though, it can’t run on a Pi and VCV core dev Andrew Belt has explicitly said he won’t target SBCs. (Although, this was a few months ago. Would be surprising if he’s had a change of heart.)

SuperCollider does work on the Pi and scsynth is used by Sonic Pi, which is included in the base Raspbian and Ubuntu MATE distros.

#18

Rack is cool, but it is a CPU hog. IMO there is put way to much weight on the UI side. It looks really sweet, but that infinite size scaling, among other things is very cpu draining. My fan is blowing full speed alost from the second I open rack.

I prefer something like Axoloti then, where all that UI stuff, which IMO is secondary in a musical applications, is toned down, focus is on the audio processing.

#19

I agree with you guys that Rack is pretty heavyweight. Someone attempted to get a build going on Raspian/similar despite Andrew's position: https://github.com/mi-rack/Rack. I tried to build it a few weeks ago, ran into a snag, gave up and tried to ping the dev. Haven't heard back so it may be a dead project.

It might be unrealistic to actually do all that DSP without specific optimization for ARM which will be tough without having Andrew on board. The raw GLFW UI tech itself is cool though and would probably be useful on SBCs in a more minimal form. Philosophically the "skeumorphic" design idea of having everything look like Eurorack isn't my favorite thing. There's no user abstraction mechanism at all; you're just stuck with the finished modules. But that makes it way more approachable to people who know Eurorack and don't care about any sort of "programming language"-like functionality.

#20

well, one very distinct specialty of axolotls is neoteny. this means that axolotls often stay in larval stage forever, and even reproduce.

so things just happen like the name suggests.

also

Unlike some other neotenic salamanders (sirens and Necturus), axolotls can be induced to metamorphose by an injection of iodine (used in the production of thyroid hormones) or by shots of thyroxine hormone.

so, some external factors can help :grinning: