would it be difficult to add an option to start a patch without starting the Patcher gui first?
so for example starting a patch from the commandline by using:
./Axoloti --patch somepatch.axo
I image this could be useful for live situations where one wants to switch patches quickly
I don't think difficult... we already have a compile option we use for testing, just a matter of also uploading to the board... (we might need to be a bit careful with timing the connection to the board) , probably an easy add.
but I'm not sure helps with switching patches, as you cannot have 2 instances running, and I assume this is to take advantage of having the UI attached... (otherwise you may as well just invoke a load patch )
so although good for a quick 'go' (and useful for testing etc) , I'm not sure I get the quickly switching patches.
... and i doubt many will want to use the command line in a live situation.
I do think we need to consider the possibility of 'attaching' the UI to a patch already running on a board, and wonder if this might make this a mute point
imagine: the board can run a patch on power up (already possible) , so then you would just start the UI and then it would connect to the board, if you then switch patches (say from a midi pgm change) the UI then 'reconnects'
the 'issue' is this is a bit away from where we are currently... but perhaps this is where to push development effort?
EDIT: as an aside, I added some time ago (not quite sure if its in 1.0.3) the option to load patches from the command line, i.e. ./Axoloti.sh mypatch.axp , should start axoloti with the patch loaded (but not in Live mode)
perhaps, but I was already thinking bout the next step, and that would be starting it from a max/msp patch, since it can simply execute shell commands on 'load' or any trigger.
i'm not sure if I get this; the procedure as I image would be like: open patch in background, compile/upload to board, close program. At that point Axoloti would just continue running with the patch, right?
repeat for next patch.
imo there are much better ways to integrate processes (including Max) than using the command line...
e.g. why not get max to just send program change messages? or use OSC?
it would certainly be interesting to hear more from people that want to be doing this kind of 'driving' from a PC.
yes, axoloti would continue to run the patch, until you ran the new instance, then it would immediately (on connection) stop the patch... so would be a small pause for next patch to load then start.
but again, i repeat, what advantage is there, with this over just getting the axoloti board to load a patch of the SDCard (say triggered by a program change) ... in a live situation, where you have a 'set' i.e. you have a list of patches you are going to use.
as far as i can see it, only that you get UI interaction (Im not a fan of using a laptop in these situations, but i can understand/respect some do) ... hence my suggestion, that this is solved if the UI can be connected to a patch thats already running on the board.
(which I admit is more difficult, technically, to achieve but perhaps is the end goal)
actually, just re-read this... now I see you just want to get a patch loaded on the board with no ui at all.
still not quite clear, why this is beneficial over just getting the board to load the patch from sd card, via a midi message... sure you can do this from a computer, but you don't have to rely on code (e.g. max could do it directly)
the only advantage i seem here, is compiling, and not having to load it on an sd card, but for a live situation that seems, an odd requirement. (surely you already know your set beforehand.. and you won't be able to edit without UI)
I do actually think though, it would be nice to have a few separate command line apps to do some common things, as much for testing/development purposes.
e.g.
- upload patch and run (as you request)
- upload to sd card , with flag for startup or not (though arguably to would be better to make the axoloti appears as mass storage, but is much more dev effort)
- update uuid/sha on object
- compile and run tests
- compile and update firmware
where some of these may be particularly useful is when using multiple axoloti boards (hence my vested interest 
), as the UI is a bit 'clumsy' for dealing with multiple boards currently, and I often just want to upload the same patch to all my boards.
(I tend to use a single board for 'development' of a patch, then just want all boards to load it... when I don't need the UI interaction any more)
note: another option, would be to 'expose' the protocol to the board (bulk interface) , just that it can be used from elsewhere, say an api that could be called from your app/max... this is kind of available already , but unfortunately the current 'encapsultation' is in Java... it would have been much more useful/flexible if it was in C/C++... and we don't want to have two interfaces to the protocol, as thats twice the maintenance.
I have a script for that already, however, it is not getting the same results for the SHA . it is not clear to me what java uses to generate the string from; it looks like it uses the address of a byte-array, and not just a string (?? )
I dont know much about java, so perhaps you (or anyone else) could help with that and post it here https://sebiik.github.io/community.axoloti.com.backup/t/how-are-uuid-and-sha-generated/484 . is the java code using UTF-8 encoding?
no, its passing a byte array (you don't get access to addresses in java)
encoding... that could be improved! the code should actually specify this in getBytes(), but doesn't which means it will use the default character set for the platform. Ive not checked the code, its possible somewhere its setting this explicitly.regardless, Id have preferred to have seen this explicitly specified in the getBytes() call, as its obviously very important here.