I don't like the idea at all about Axoloti automatically making inlets for every parameter. Unless I have the option to delete them again.
There are 100's of examples of effects where you dont need inlets.
First example; you can control everything form midi cc, as mentioned = no need for inlets.
If you for example have made a saturation object or a drive object, in most cases you set the settings once and move on. If inlets are auto created for these parameters, that don't really need them, they will take up extra screenspace and & also a bit of DSP resources.
I'd say not even half od the parameters I make I need to use inlets for. So in theory it sounds great but in practice I dont really need it.
Maybe the problems you and Blindsmyth speak about are what Mark was referring to. A cool way to remedy that would be for knobs and inlets to have the right-click options 'Enable Inlet' and 'Disable Inlet' added to them. And if a control is set to "Enable Inlet", there could be an 'Options' for it in the same right-click menu. Maybe even keep it as no inlets by default
Axoman, when I first got the Axoloti I also had 100's of suggestion what to make better. But better is always a very subjective thing; what is better to you might not be better for me.
In general things that might add extra load on the DSP's or the memory I don't like those suggestions, cause Axoloti is limited in its resources. And I would hate that Axoloti had all these "smart" features.. That might be smart, but if they take up extra resources that I could use for something else, I really don't want them at all. In general anything that takes up precious resources from Axoloti, which is fairly limited in some areas... I really don't want those things implemented.
Even if they makes things easier.... If Axo can all ready do it, I dont find any reason to be able to do that thing in 2-3 other ways, especially not if they take up resources. And I think that is also some of Johannes and Marc concerns when it comes to these things. Believe, me, I have been nagging them for years for some things
BUt what I do would like to see, is like FFT processing and phase vocoding and stuff like that. Things that we cannot do. And also a better ways of handling parameters, so we also can control for example the ctrl/i with midi cc, stuff like that.
I hear you, but the lack of inlets (or easy creation of them) is a different thing though.
Inlets are the essence of the program. A layman sees Axoloti and expects he can solder a knob to his Axo and it will drive his creation. Fact is though, it's not that simple due to inlets not being 'always an option to the layman' without having to hack code - and laymen don't hack code - it's one reason they chose an Axoloti.
The problem you and Blindsmyth describe would be eliminated, cause by default it would create no inlets, and so by default, no one would have to do what Blindsmyth is doing now, manually having to remove unused inlets. So it's a problem both ways, and the only way to solve both of them is to not add them by default, and make it easy for the layman to add them whenever and wherever needed.
If that were possible, then it would please everyone. It would even lessen memory requirements
I often asked for things that the developer didnt find necessary, so I learned how to code it myself. And have been happy ever since
Hm.... I don't agree, I chose Axoloti EXACTLY because it is customisable in all ways. My thoughts are; maybe Axolotis is just not the tool for that layman that don't want to work a bit for it? I'd say if someone wants to play around with an open source DSP programming environment and expect everything to be served on silver plate, I am thinking they maybe have the wrong expectation of what they are getting themselves into. I think they should at least expect to have to adapt to the platform and not expect the platform to adapt to them. Atleast when still learning everything.
And adding inlet is, in most cases, really really simple to do. So if they simplest edit of an object is making a layman too confused, maybe Axoloti is just a too deep platform to venture into. Maybe something less deep would be a good place to start and then later on take the next step down the ladder.
I'd suggest learn to make your own objects by looking in objects and see how they work. Ask questions..... This is how I learned to program Axo objects and I rarely need to ask questions anymore, cause I can now do a lot myself. I have never in my life written one single line of code before I got Axoloti. And I think in maybe 6 month I learned to do this and can, from all ready existing objects, almost make ANYTHING I like, from reverbs to complex routing matrixes Not saying I understand everything I program 100%, but hey it works...
Next step for me it to be abe to actually code the individual parts by myself, instead of copying from other Axo objects. This will take a while I guess, but I really don't want to be dependent on other peeople when it comes to these things.. So only solution = learn it myself
Since I know how hard it can be, I try to help anyone asking questions about the code that I can answer. And so do many others in here. So there are a lot of helpful souls in here Anyway, my point is. Just dive in and become a happy camper later on
I can't see any reason why you would have any problem with anything I said in my previous post.
Axoloti is designed to enable the layman to create without the need to wirite a single line of code. Laymen don't hack or write code, nor do they expect to do so in an object-based environment designed to eliminate that. You're not a layman, Jaffa. But me, when it comes to programming, I'm a complete layman. My strength is in sound design and the design and engineering of physical products. But math and programming aren't my thing, never will be. It's not that I can't learn it, or too lazy to learn it, it's simply that I don't want to learn it, which is why I got into Axoloti.
You know what the most useful object I ever used in the Axoloti Patcher was?
It was that little helper gadget Sputnki made for me. Such a simple thing to Sputnki and the math guys, but MASSIVE to myself in that it allowed me to understand functions in almost an instant. I'm eternally grateful to Sputnki for that, cause without it, I would never have learnt about functions.
A layman coming to Axoloti, say, a guitarist who's pissed-off with not having the sort of stomp-box he needs. He sees Axoloti, no programming required, just link-up the objects and off you go!
Well no, no he won't, cause at the moment, if he asked on the forum, people are gonna tell him to "hack the code", or "learn to code". Now if he's polite, he's gonna think to himself, WTF, I bought this thing so that I didn't have to concern myself with all that stuff - and he'd be right - he shouldn't need to.
I can easily split my requests into two distinct categorties; 'Missing' and 'Would Like to Have'. And to be honest, I always feel bad about requesting features cause I know the amount of work must be immense. For that reason, I try not to mention stuff unless I think it's "Missing".
Ability to stream even two channels to/from the SD card - Missing
Control over inlets - Missing
Spectrum Analyser - Missing
I think the only feature I ever requested apart from those I consider "missing", was to improve the way objects can be searched for in the object browser, so I suppose that's the only one would fall under "Would Like to Have", but the others are definitely "Missing". Everythihng else, I do as you suggested, I ask how to do it and the peeps here help out - which is awesome and always greatly appreciated
... BTW, I do intend to get into basic programming as I've chosen to learn PICAXE so that I can develop my own display driver boards. I intend to do that so that I can design boards to my own specifiction, ones that I can reuse in various products of my own design without the need to redesign them.
So I will be learning some programming, I'm not too lazy to do that, but I shouldn't need to learn how to hack C in order to use Axoloti. Of course I will do so at a push, but I'm simply pointing out the flaw there, cause I shouldn't need to do that.
I am also just a humble layman, who got a bit feed up with the whole commercial line of audio equipment out there. Like seriously fed up with marketing guys telling you lies, to sell more products.
Regarding Axoloti, I just decided I dont have time to wait for other to start thinking that my ideas are good and then consider implementing them. So I dug into it myself. And really happy that I did
And I am willing to help anyone who want to do the same
Hm, I dunno. I havent read anywhere that "Axoloti was easy, just connect and you are good to go". I read "Axoloti is 100% customisable, build your own stuff"..... haha and when I read that, I don't expect anything to be easy. So that makes is very subjective and I have never expected it to be easy.
But yeah, i do understand the scenario with the guitar player, just want to make a few custom effects that he couldnt make on his guitar board. I do get that.
But I also think that is good to keep in mind that "custom" dont comes easy > either you pay for it with €, by buying a device that can do that.. Or you pay with the time you have to learn to make it. My point is, when working with these low level environments, I think one must expect that learning new stuff is a huge part of it And believe me, I have almost thrown all my Axolotis out of the window several times over the last few years, hehe Glad i didn't
Oh and +1 for the object browser some kind of fixed version would make me happy
So when "Axoman industries" becomes coding compatible, I'd like that to be my first request, the object browser
The point is also that leaving the knob on the object fixed will eat up more ram than using an inlet and const/i for example. (this is also why I want to have a const for fractional)
Eventually it comes down that all UI elements of the patcher like knobs, buttons but also scopes, disp use up ram that I prefer to use for my soundengine since I use controllers gpio in the end.
In that sense I like axoman's suggestion of beeing able to more easily add/remove inlet or knobs. On the other hand diving into the code by simple hacks you also learn a bit more what's happening under the hood....
It would also be cool if you could also deactivate/acitvate visualisation objects like scopes and disp so you can use them for debugging / visualisation if you need them and otherwise leave them out of the compiler to save resources.
Cool, didnt know that I mostly use Axoloti together with a computer and havent actually ever used it in stand alone mode, so I like to see the dials. And actually dont use that much midi controller either, mostly just to turns things on off.
Sure good point. I havent ventured much into using Axoloti in stand alone mode. But good to know when I get there. And I often hit the DSP wall(in every patch, actually) so great to know these things
as such 'display objects' do not really eat up ram... parameters DO... and parameters are not just about display, as you will see when you get Axoloti Control
Parameters are 'variables' that can be changed at runtime, as opposed to Attributes which are compile time constant. as i think i mentioned earlier, Johannes and I have discussed this before in the past, what we would like is for the distinction between inlets/parameters/attributes to become more 'fluid'
Ive proposed we actually do away completely with attributes, instead what we will have is Parameters, that you can right click and say this is a fixed value. users will then learn the tough reality... nothing in life is free, you have all your parameters as variable, then your patch wont be as fast/will consume more memory... fine for small patches. more complex patches, you'll want to lock down everything you dont need to change at runtime.... but the key is its the users choice, and they get to live with the consequences (actually for performance reasons, it'll probably be fixed by default, and user choose which to make variable)
this will also help with axoloti control, since you can expose less parameters, so its easier to navigate.
inlets for parameters, as I said, its kind of an idea/proposal thats knocking around, the issue is some objects already have these manually coded, so then there would duplicates, and if we remove, we have the danger of breaking patches! (and yes, we have had lots of discussion about backwards compatibility, and object migration... which is another huge can of worms)
displays... again will be viewable in axoloti control if your connecting to a computer, then yes, when display values changes, there is some usb traffic, apart from that yeah a small bit of memory to store... so I guess theres an argument for disabling, though how long before we get complaints there not working coz they've been disabled
of course, the other side is ... you could structure your patches differently... put your sound engine in a subpatch, and then the UI / GPIO in different parents... then for debugging use the UI variant, for performance use the GPIO variant.
... I have to say, I tend to use a strategy where I try to not have too many UI objects, so I agree on many of these points, just I'm hoping we can get to fixed parameters to solve this.
I think this is rather exaggerated, different users have different expectations, even with just factory objects, there are huge number of things you can build with Axoloti.
saying its 'unusable' because it doesn't have a feature you want is a bit excessive... especially if there are other ways to achieve the same/similar... no piece of software or hardware, can do everything, everybody wants...
so sure, if you are a programmer you can extend it more... do more, of course, its the same with PD, those that can write externals can make it do more... but heres the thing, its this ability that allows community programmers to given non-programmers new objects!
also this is why Axoloti is open source... unlike (e.g.) Reaktor, it is possible for others to update/contribute to its development..
It's not exaggerated. The guitarist in the example scenario I gave is going to put some time into connecting-up the cables to make his ideal patch, then he's gonna wonder why he cannot connect the input pins to a lot of the objects he's used in his patch. You are a coder, you help develop Axoloti, so these things are second nature to you, you can do this stuff without even thinking about it. That is not so for everyone who's going to be attracted to Axoloti due to it's accessibility. I'm telling you this cause I was one of them!
So don't get defensive, Mark, I'm pointing this stuff out for a reason.
Same with the SD card situation, there's no full-duplex object, so despite it being a development board with Stereo In, Stereo Out, and SD Card Read/Write on board the device, it doesn't even allow basic stereo streaming from the SD card while streaming Stereo to the SD card. In fact, it doesn't stream at all. Hopefully we'll get a full-duplex object to remedy this, something designed for super-optimized full-duplex streaming operations. But regardless of whether we do or not, I'm simply pointing it out because it's an obvious yet unexpected limitation.
So the argument you're using works both ways. You can listen to this stuff and accept that it's a limitation, or you can hate me for pointing it out, just because, perhaps, it's difficult to implement. And if that's the case (and I'm guessing it is otherwise it would already be there), then I'm sorry to hear that, but I can't help that.
If the features (or lack of) I point out get sorted, that would be fantastic. And if they don't, well, I'll accept it just like anyone else would have to accept it. I'm not going to be apologetic about it though. I'm pointing this stuff out because I personally feel they're missing from such a product - which they are.
I never said it was unusable.
But I'm not a programmer, so I'm telling you this stuff from a non-programmer perspective!
Cheers mate, but I already know how to hack the code, Sputnki taught me a while back
Like I said, I point this stuff out because it's missing, it's not just for my benefit. Well ok, maybe just a little bit, but you know what I mean.
I'm basically just pointing things out that I feel 'belong' the system that is Axoloti, and things that have tripped me up along the way, and will trip others up along the way. I just feel like I'm pointing this stuff out to help Johannes refine the product in areas he and Mark might not spot themselves due to them being super-brains. It's easy for super-brains to assume everyone else is a super-brain.
And then there's me ... who hardly has a brain at all
I think we need to ensure we don't stray away from the open source perspective that that Axoloti has. Additionally,"Guitarists" are willing to roll their sleeves up and learn to program in "C". And this idea is becoming more and more popular amongst guitarists. But on the flip side, we do see closed source items hitting the market where there is no coding required. But you get what you pay for and that's that. I think it is wrong for anyone to take up an open source product with the expectation that they will have access to everything they need when they want it. But the best thing about open source, when you least expect it, someone will come along and provide a solution that you can also benefit from. Just look at the available source code for Arduino, its not so much Arduino any more, but any board that can be programed by the Arduino IDE. But not all the dev boards can do the same thing, they all have different setups voltage references and options etc, so often you need to ensure you are choosing the right board for your task. This all may not seem relevant to this topic, but it is, because the Axoloti has its specs and has its own limitations, and those working on it, have prioritized what benefits most, and will continue to do so. This doesn't mean Spectrum Analyzer won't developed, it just means the comes comes with developing a product under an open sourced environment is what it is. I have read tons and tons of Arduino related posts that sound very similar to this one, and often with more complex tasks, unless you can convince someone to do it for you, you roll up your sleeves and do it your self.
But I am going to say one thing that may come across quite harsh, and I more than expect many may disagree with, and that is, anyone who buys into an open source product does so at their own risk. You do need to accept they you may not be getting what you expect, and that even the product and community may not be able to provide you with what you require. To me, this is what I expect and nothing more from open source, and to get more than this is nothing more than a magical bonus.
For me the best thing I could get for my Axoloti, would be more ram and processing resources. This would be far more useful to me than a spectrum analyzer that I already use from the axo out into my soundcard then to a free analyzer I downloaded.
Not sure which API is available for Axoloti, but most FFT libraries use cfft() and rfft() to distinguish between complex and real inputs, not outputs. In my experience, all of the routines produce unscaled complex outputs. If you want real outputs, then you'll have to compute the magnitude of the complex values by calculating the root of the sum of the squares of the real and imaginary parts. Then, since we make the most sense out of decibel graphs, conversion from linear magnitude to logarithmic decibels would make sense. You can skip the phase calculations. Some FFT libraries even have this rectangular to polar conversion as a separate function.
In other words, I doubt that you'll have much luck if you expect rfft() to produce real output. As I mentioned, my experience is that the 'r' refers to real input.
Weeeeeeeee're off to see the wizard, the wonderful wizard of ours. His name's Johannes and just the man, if you want a wizard of yours. And always remember it's open source, and open source is just because. Because because because because because, because of the wonderful things it does! We're off to see the wizard, the wonderful wizard of ours ...
Hey axoman, if we manage to reach the great wizard of Axoloti, what would you ask him for?
I would ask him for a Spectrum, I would even help him make 'em, if I only had a brain ...
I believe a full featured spectrum analyzer would be nice to have but not critical. The Clavia/Nord G2 never had one (not even numeric readback of values in a patch) for example.
Streaming digital audio to the PC over USB is not quite easy. I have heard demands to make Axoloti Core work as a USB soundcard, but my estimate is that this opens a can of worms. USB soundcards have the choice of synchronizing the sample clock to USB (there is a start-of-frame at 1kHz that would need to be the reference for the audio clock), or being audio clock master (transmitting a varying number of audio samples per USB frame). When it is a clock master, the clock will drift (no matter how accurate) compared to other (usb or non-usb) soundcards in the PC. A pro soundcard sync'ed to a wordclock input will sync to wordclock not to the USB clock. Operating systems can try to hide this by software-resampling, but this introduces latency and resampling can be questionable. Configuring a DAW to use multiple (clock-drifting) soundcards may work for some and may not work for some. In this perspective I believe developing Axoloti Core as USB soundcard would be complicated, sinking a huge amount of time, with questionable results. But ok, just for spectrum analysis there is no need to expose it as an audio interface or synchronize with anything else. It would be the next feature request I get when audio streaming is there just for spectral analysis.
But for running spectrum analysis on the PC, there is no true need for streaming audio. The only thing needed is transferring snapshots of long audio buffers (tables) from the board memory into the editor, long enough to use for the FFT, then the editor could compute the FFT. It requires to the table contents not to be modified during the transfer, as the audio computation cannot be interrupted for the duration of the transfer. I think this is a more interesting approach than full audio streaming. It requires exposing the memory location of table data to the GUI, and far more advanced interactions between an object in the GUI and an object running on the board. And then one could wonder, why just fft-spectrum, there are so many other math/dsp functions and data visualizations that would be neat too. So that would rather demand running scripts in the GUI, and linking to a math/dsp and data plotting library. All those GUI-sided script functions would not be accessible when playing a patch without PC connected though, such functionality would not be midi-assignable or integrate with inlets/outlets. I think this is a better direction than audio streaming. Reading/writing to tables from the GUI is on my wishlist, and one significant step. GUI-sided scripting too but that will not make it into the next release.
Available objects for spectrum analysis have their limitations, I'm aware. @rsdio: currently the CMSIS API for rfft/cfft is exposed. I'm tempted to replace those with FFT4CM4F. I'm currently focusing my efforts on framework improvements rather than adding object #201.
On full-duplex streaming to sdcard
Again, there is a lot of music gear out there that has some sort of storage and audio ADC/DAC, but not able to playback or record. But I do agree that it would be nice to have full duplex playback/recording.
The technical story: there is bit of an conflict-of-interest, for sample playback small buffers are preferred to minimize start latency and sdcards generally do not perform much worse when reading small buffers compared to large buffers. On the other hand, common sdcards perform terribly when writing small buffers. For full duplex, large (file)buffers are required, also for playback, otherwise writing will not finish in time before fresh data needs to be read. I did some efforts on full duplex streaming playback/recording long long time ago (before Axoloti was released), it only worked intermittently... A lot of things have improved in the meantime, I believe it is well possible with sufficiently large buffers. Again, currently my development efforts are focused on the framework.
Bit of both I suppose, I just changed the lyrics to that song from the old musical called 'Wizard of OZ' (the original movie). I'm surprised you didn't realise what it was, but then again, you don't live in the UK where they show the thing every Christmas like they do over here - lol - or at least they used to. Haven't had a TV for years, so not sure if they still show it today.
Thanks for the in-depth explanation, I appreciate it, but really, I'm not as obsessed with getting it as people seem to think I am. I keep trying to point out that I was just "pointing it out because it's missing" and hoping we get it. Well at least I can stop hoping for the spectrum now, so no worries (it still should have one though).
Sounds like the SD full-duplexing thing might happen in the future then, so that's cool I understand about 'framework first' - best way of course!
Even though spectrum analyzer output is not audio data, it still can be useful to use Isochronous endpoint streaming to deliver frequency data to a USB Host.
I agree that USB Audio implementation would not be easy, but I don't see it as opening the can of worms that you think.
None of the professional sound interfaces use the option to sync the sample clock to the USB frame rate. That solution produces poor audio quality and has basically been abandoned except for very low quality USB Audio interfaces. So, basically the only reasonable choice would be to allow the axoloti to be the sample clock master, both on board and over USB. This simplifies the axoloti code to some extent.
I suspect that the biggest problem would be the CPU performance lost by enabling USB Audio. There should be an example implementation of USB Audio from ST Micro, so it shouldn't be too difficult to try this out.
CoreAudio, which is part of macOS, always runs an audio device as the master clock for audio data. This is never a problem when using only one audio interface.
I suppose that the axoloti might be more likely to be used in complex setups where multiple audio devices are being used at the same time, so you have a point in that respect. CoreAudio does allow for the creation of aggregate devices. In any event, the code that runs on the axoloti CPU would not have to deal with this under any configuration. Are you saying that the axoloti development would be difficult, or that user configuration would be difficult?
Ideally, spectrum data is a continuous stream just like the time domain audio samples. If you create a data path that isn't continuously streamed, then you run the risk of seeing inaccurate results due to events in the skipped sections. I suppose that if the axoloti were to calculate a continuous FFT and then average the results to report the spectrum 24 times per second, then that should be fast enough for any reasonable video display. This latter option would not require real-time streaming since it would hopefully be very low bandwidth. I think that even 60 fps is overkill for spectrum display. However, even though the bandwidth over USB would be reduced, the CPU bandwidth would still be quite significant.
Thank you very much for this information! I was not aware of FFT4CM4F, but I will probably make use of it now that you've shared the knowledge.
In my design experience, you can't skip the step of recording to fast RAM. Recording directly to SD card without buffering in other memory would be sure to fail. Instead, just make sure that you have a large enough RAM buffer to support the requirements of the SD card write size, and you should be good.
