There's really no rush, don't tackle them all - and to clarify your title re-wording i don't have one yet (Not yet new !), so i can't try things out, but i get it that it'll be a useful title for users in a similar position to me.
I'm trying to be mindful about the breadth of distraction i place on myself, so i'm in part trying to foresee potential issues although as i said, it's a gadget with my name all over it on first glance !
Potential user - general questions
I'm running the newest Axoloti Patcher on an old OSX 10.9 with an old Java SE 7 runtime, no problem. I'm sure it doesn't care at all about Xcode.
a bit of an overview on answers since quite a lot of questions, feel free to ask for more details, and I'm sure others might add some more 'flesh to the bones'
there are a few youtube demos, but as you say like most synths, its rare to publish things 'raw' as its never complimentary when compared to other synths swimming in reverb
there is also a huge set of combinations to explore with things like filters, and you can also do wavetables, samples.
...hmm wil have to think about this.
you have to take the patch live i.e. send it to the board and run it.
so load it, take it live ... this takes a few seconds.
but you cannot just browse.... interesting idea thought, to perhaps save 'previews'
I think the latency will be very good, usb in is processed 'immediately' and then processed at 3khz.
Ive used with the soundplane (so alot of data) and didnt notice any latency.
yes, 'easy' to do with patching.
we do support sysex on midi output for usb, it could be added easily for din
the reason for no input as yet, is sysex messages can be of arbitrary length, and axoloti has 'limited' memory... this means we would have to do 'byte level' processing, and even then the user would have to be careful with memory.
(we allocate memory upfront for the patch, so as to avoid dynamic memory allocation and GC etc)
so no, its not a fundamental limitation, more really down to thinking 'how to do it', and also discovering what use-cases people have.... why do they want axoloti to process sysex, or is it just 'midi thru'
Im not quite sure what your driving at... you can code your own custom objects in C++.
obviously there are some 'framework limitations' e.g. how we send midi around..
again, not fundamental limitations, just what we expose in the 'api'
we don't use Xcode... 10.9 is fine....
java is installed by apple... so you'll be fine
I'm sure @johannes will answer this.... there might be some answers in the hardware faq in the user guide section
hardware its all possible.... slicing etc there are some objects, but as always the 'devils in the details'
it can record to memory, no saving to SDcard, but this could be done, the 'trick' is to do this without having audio glitches,
Im pretty sure the shipping version is not scheduled for any updates
(the only update so far, was adding a bit of extra protection - to avoid an issue a very small number experienced.. there is a detailed post about this somewhere)
again, @johannes will tell you stock levels, I think the website is accurate?
patches can be selected dynamically from computer UI, or by dynamically e.g. via midi messages , gpio etc.
im a user/contributor ... and a fan of axoloti, but don't have any kind of 'investment'...
so heres my opinion, also based on alot of what I've seen on this forum too.
Axoloti is extremely flexible, and its easy to get things patched together using existing 'objects'.
where some have 'fallen foul' is like any modular environment, its designed for you to patch things together rather than be a 'complete system' you plug in and just go... so it does require investment of your time, and the more complex a system you want, the more time it will take!
also, the best way to approach patching (I think) is also to be flexible/creative, sometime an object might not do exactly what you want (e.g. to emulate a piece of hardware) , but often, you can adapt...
also, im not saying there is a limitation to the axoloti hardware, I think its great, but obviously a G2 is 1000 euro (used) and an axoloti 65 euro (new) , so expectations have to be 'managed'.
at the end of the day, like most things (especially complex things) the more time you put in, the more you will get out...
on a parting note (hope this doesn't upset @johannes ) , kind of summary...
if you want think you will enjoy, building things, something new, something to your own desires. Axoloti is fantastic... much better, than say a PI/Arduino (imho, due to the integrated software environment)
if you think you want to emulate a piece of hardware, then you might want to consider how complex that device is... what features does it have?, what do you need? then consider the time required to build this, using basic building blocks... then is that worth it to you?
(your in a good place to do this, as your used to Max/MSP so its going to be similar, albeit you have a new learning curve)
anyway, too much waffling, but I hope some of this may be useful, and as I said at the beginning if you want to 'dive' in to more details, happy to answer more questions.
Cool - it's only something I asked because another user posted about it causing big headaches - but good to hear Mavericks is fine although not the officially supported testing environment - I'm not changing the OS
we only really have an issue with 10.7.5, as its such an old version of java. I know as Ive a couple of old macs that are stuck there. 10.8 I'm not sure about, as i don't know its java version - not sure if anyone is using. 10.9,10.10 and 10.11 are fine. (Im running 10.11.6)
oh, @avantronica something I forget to add, which is a major 'thing' - the axoloti community is really strong, and has been building up the Community Library * at an amazing rate
this is a huge asset not to be underestimated, there are some great objects in there, and its fun seeing what everyone is coming up with - its hard to build up a great community.... so I guess this also a testament to Axoloti
thanks to @cpwitz in the community we now have a great online list of objects available:
(*) The community library (using, and contributing), and an object editor to create objects is built-in to the Axoloti patcher.
Sounds promising .. does this imply these user 'objects' are sub-patchers based on internal objects or are these contributions from peeps getting stuck into c++ (which i've not used)
the more uncovering that's happening, the more i'm hooked, seeing the internal object list e.g. gives enough additional clues - again, i haven't searched exhaustively but i couldn't get a quick feel for what's connectable along the back edge in terms of the full definition of all the pinouts, nor am i sure on what the large cluster array of pinouts are for
obviously all i/o etc - but details help to fire the imagination
so the object editor sounds intriguing
tbh - ordinarily i'd have just downloaded the editor to get a feel - i presume it can run without an attached device (just not compile etc)
but with all the command line stuff and this here, that there i don't want to go installing things that may be harder to wipe if needle - plus i do not seem to be running java, based on my terminal enquiry or web testing - so i'm faced with the uncertainties of installing a somewhat frowned upon package ?
If anyone can assure me it's trivial to remove a test run of the editor i'm sure it will tip me over into joining once i see the toys : )
a user in another forum piqued my interest and mentioned reverb, but i didn't see that listed as an object EDIT: strike that - very long list with repeat groupings
ps - i'd really appreciate knowing now what the total delivered price will be, even in euros though i'll buy for uk delivery - is it 65 + tax + delivery ?
you can either build sub patches with 'patching' or custom objects in C, both can then appears as objects. (sub patches, you use the normal patching interface, the C objects use the object editor)
and both can either be in an 'external file' or embedded into the patch.
i/o, quite alot of options, if you look at this post. this shows some example circuits, and also you can see each 'pin', and if it can be a digital in/out or analog in/out, or used for spi/serial comms. in the hardware category, there are some details of things others have done.
uninstall editor, simply delete app and the runtime folder (you installed), and the ~/Documents/axoloti.
nothing else is installed, except java if necessary... and thats an official apple product.
yes, It'll work with a board... but as you say, you wont be able to hear anything without hardware, or take the patch 'live' (and so see the performance side of it)
... Im a developer, and also use same machine for music, so like you I need to keep it 'tidy', so its good that Axoloti doesn't install drivers/startup files etc
price, yes all euros + vat + delivery... if you add to the cart, and hit calculate shipping, it'll tell you the total amount. (before you have to give payment details etc)
£69.55 inc vat and shipping (small parcel, signed for) from the above mentioned retailer.
You can find the pinout Here and in the user guide. So far stuff like buttons, switches, potentiometers, shift registers, addressable LEDs, spi ADC chips and other devices via serial have be connected.
Sub-patches are a thing in their own right, they're patches that you can use in other patches e.g. say you built a mono synth as a patch but now you fancy its sounds as a poly synth, you would turn the mono synth into a sub patch and tell your 'new' patch to use the sub patch 8 times to give you 8 note polyphony.
In answer to what I think you meant, it's a mixture of self coded contributions and edited pre-existing objects. So essentially, you can build what you like with pre-existing objects, if they don't suit your use case, you can make a copy and add your own code to it to make it do your bidding, or if there isn't an object that does what you want, you can write it from scratch as well, as a new user myself I have been adding code to existing objects.
Java is frowned upon as a web browser plug-in, yes, but not as an application environment. AFAIK Apple nowadays keeps the plug-in deactivated by default, so Java is just sitting there waiting to be used by something launched by YOU. Java-based applications are not more or less safe than native executables. Well, some programmers don't like Java. But you are a user.
Here are my answers, possibly some overlap with other's answers:
I believe they're pretty "straight", no simulated drift or jitter.
Different algorithms and compromises between cpu load and quality can be made. A huge difference with the Nord Modular and G2 is that Axoloti is open to community extensions.
I have not done any specific latency measurements on usb host, I believe the dominant factors will be their respective transport protocol.
Implementing Sysex reception in realtime can be a source of trouble. Not impossible, but so far the balance between effort involved and interesting additional uses cases did not trip.
Around 2Vpp of the line out and headphone out.
There are also 2 GPIO's (solder pads) that can serve as 12bit/3kHz analog outputs, with 0-3.3V range.
SD*card* can only be accessed in buffers, and the smaller the buffers, the worse the performance gets. That limits its use to non-transposed forward playback, jumping to a new position is possible but limited to multiples of 64 bytes.
Files can also be loaded into "tables" in the 8MB onboard SD*ram*. That has much better performance for random access. 8MB corresponds to ~83 seconds at 48kHz/16bit mono, and is fully available for patches.
I have done some tests on sdcard recording long ago, my conclusion was that it requires larger buffers than required for playback, which makes it hard to do both simultaneously.
There is currently no hardware revision of Axoloti Core are in the pipeline
Roughly 1 week.
You can create a "patch bank" that associates patches with an index, and trigger loading the indexed patch with a midi program change, to enable this, you go to preferences, enable "Controller Object" and enter controller/pgmchange
as controller object.
thanks all - lots of useful asides, certainly whet my appetite, i'm sold, now it's just about juggling my time spent noodling with endless-bottom tweaking and actually achieving things without spreading myself too thin and only i can answer that, but it's certainly appealing and very deep
I'm increasingly beyond the point of no return, i certainly want one - just need to get on and get one
I think there are a few utility devices that if you can shape shift an Axoloti into effortlessly, then it pays for itself on day one .. the rest is all bonus
A MIDI synced stereo looper would be one such usage case that springs to mind
I have every other permutation, but no (non-time-stretched) stereo synced looper device
Are there any obstacles in and around this area that i should be aware of, i guess i'm thinking that there could be issues if the clock was sloppy and a loop length got defined at a slightly short/long point depending on the ebb and flow of the incoming clock - now is the loop playback likely to be driven by the midi clock thereafter, or is it more likely a looping Axoloti patch will just repeat a buffer once it's defined - i'm also guessing some of this is up for grabs if you want to code it - but in principal - are there fundamental roadblocks to achieving a robust stereo synced looper - and what might the memory constraints be in this example - i presume long loops are not a problem ?
This aspect alone would be the clincher, but all the fun would be had in doing the creative patching for sure : )
Any thoughts ? I've seen the looping video btw
One last pre-receiving Query, I have read and browsed, but it's actually not that clear whether the SD card is obligatory
I don't have a spare, so I wonder if I need to order one of those to arrive in time too
My impression is that it's optional, but I'm not sure
I can see a few threads from a way back discussing aspects that may have been coming on stream
Plus the long thread describing lots of card benchmarks
But. can someone advise on these
1) Is it absolutely critical to functioning ? (i guess not)
2) what is the best budget card that covers most normal usage cases well, or what is a minimum spec to avoid the first issues one might come across
3) I have no interest in streaming large files or storing lots of potential samples to use (i don't do that on the OctoTrack even) so i'd like to know what functionality (currently and coming) might I exploit by use of a card and is any of that likely usage going to be requiring any notable capacity (is there any need to get a card beyond 4Gb?)
4) once the card is formatted on the Axolotl -does that force me to do file operations via the editor
?
Many thanks
If you want to use samples or save data for recall later, Sd-card is a must. You can use Axoloti without Sd-card no problems, but it will give you some limitations.
IMO getting an Sd-card is important. It is really cheap, so just get one you wont regret it I am not sure how to actually use those benchmark data either.... I just got one form supermarked and it worked Mine is Micro SD HC 8gigs from Nashua developer... Dunno if it especially bad/good... It works pretty well..
its optional
1) critical - no
(Id say its a bug if this creeps in)
this is i think a bit important, as an axoloti could be in an installation running 24x7, and I think in that scenario some may want to avoid sdcards
2) anything should be ok, if performance is not a criteria
(e.g. data streaming during audio playback)
3) other uses:
patches can be stored/recalled from SDCard, so if you want to switch between patches (without being attached to a computer) you will need one.
presets (not implemented yet) , at some point we will allow presets to be recalled from SD.
(currently there is a preset manager in the community library which does something similar)
any other data!
its a modular environment that can be extended, so potentially any user data can be stored there
... one obvious example is wavetables, but anything is possible ... e.g. musical sequences, midi files, and whatever is the community can dream up.
4) no you don't need to use the editor
its a standard fat format... formatting on the axoloti is more 'precautionary' than anything.
you can use the sdcard in any card reader etc.
also note: the editor allows you to put the axoloti in 'mass storage mode', so you can use your normal file manager. (so you don't need to use the 'internal file manager')
tip: use the smallest capacity SD card as you need, not only cheap, but likely to perform better.
so my advice, if your not streaming, just use any (cheap) SD card and leave it in there... (its what I do)
... then later if you get into streaming etc, you can get a faster/branded one
I picked up a
Sandisk 16GB Ultra Micro SDHC 80MB/s UHS-I Class 10
as it was about the cheapest way I could buy something genuine (under £5 delivered)
Looking forward very much - I installed the Editor in anticipation .. I should get the board before the card, so there will be no delay in getting started
I can see the getting started threads - but might there be wonderful tips on best practice and organising things to keep it easy to maintain scattered through many other threads - anything (brief) that comes to mind in terms of keeping it all neat (if this was a discussion on Max/MSP etc i'd have my own take to share about keeping on top of user content and external extensions etc)
I also don't like apps which create additional folders within the Applications folder (it's already too busy)
I guess it will be easy to move this or package it so it's within one 'app'
It also doesn't seem possible to create without the device, have I missed something, I can review existing patches, but wanted to test the patching mechanics and see the suite of modules (i'm 99% sure this is a premature noob comment)
yeah, the reason for the runtime, is its quite large (includes gcc) and doesn't change... so we wanted it separate, and this is the 'easiest' place for users to place it. (ideally it would go in application support)
yes, you can move it... and then in File/Preferences change the runtime path to where you have moved it to.
you can run the Axoloti UI, and create and modify patches without the board... so Im not quite sure what your referring to. (as if you can 'review' patches, then you can edit them...)
perhaps read the user guide...
(to see list of modules , use object browser by double click canvas, or press N or spacebar)
you cannot run the patches without the axoloti board, as the code is specific to the axoloti core board. (this is why the 'live' button is inactive)
(also if you edit the axoloti.prefs file, you will find an 'expert' mode which allows you to compile the patch , but really no point, as you still cannot run it ... this mode/option is really useful when you are writing your own C++ objects, and so just want to test compile... as you may have made C++ syntax mistakes - obviously not going to happen if you are using 'pre-baked objects')