Ok I found out what the issue is. If I move the tabfiles to the song folder(created when saving the patch) on the sd-card it works. But it would be really nice not having to copy these tabs to each song folder for them to work. A "general" filepath would be nice
Also if you save a patch to hard disc it creates a folder on the sd-card. So if you save a lot of different version of a patch while developing it, you will end up with hundreds of empty folder on the sd card. And also having to copy the tab files each time you save a patch.
As mentioned above the audio files works even with out moving them to the folders. Not sure what is different with tab files.
ok, moved this where it belongs ... all 1.0.8 talk here
tab files... I think you need to discuss this with @johannes ... I think this is the new functionality related to files automatically being uploaded to the SDCard, which I've not played with yet. (been too busy on the library stuff!)
Ok, I think your missing the fundamental change... now everything has to be in a library.... and you can have as many libraries as you like they can either be cloud based (git) or local (i.e. directories)
a library has a defined structure
librarydir -> patches
-> objects
(more are likely to be added later, along with some other 'meta data')
so for every place you had objects , you should create a library
and you previously had Acid and DnB on your object path, then these are converted by creating type: local library : Acid local dir : ~/Documents/Acid/
type: local library : DnB local dir : ~/Documents/DnB/
AND (this is important) move your files into a library structure so .... ~/Documents/Acid/objects/drums/esnare.axs ~/Documents/Acid/objects/synth/moog.axs
~/Documents/DnB/objects/drums/ekick.axs
it will take about 2 mins to do...
I will point out a couple of things, you only really need these libraries when the subpatches are used in many projects, otherwise you should include them into a main patch using ./esnare.axs , putting too much stuff into your search path WILL become unmanageable as you add more and more stuff! I also personally use alot of embedded patchers, for this kind of stuff, they cut n paste, and there are more convenient that having tons of these things littering the file system.
Structure patches and objects (like using libraries) will allow us to do a lot more interesting things in the future, it also makes things manageable, and easier to allow sharing.
so , I know its new... and your used to the old ways... so theres a transitions, thats the prices of progress (yeah, I could have migrated the object paths, but for the number of users using it, it wasn't worth the effort, effort and time better spent on other improvements!)
I do understand that libraries are new and I have to udnerstand it a bit more. But what I have learned from playing with it today is that I can only set 4 libraries in preference. If you try and add more that 4 it will just substitute the last one added. I added my object library folder and when i tried to add another library, a, fifth, it just deleted the last one. First 3 is already occupied by factory, home and community library. Then there is only one free library folder left.
This is more like a backwards compatible issue. I have hundreds of patched which uses those filepaths. And I have used two libraries in preferences for that and can now only use one. I understand the changes and they are good but would be nice to atleast have the choice to use more than one folder. I do have plans to use new system eventually, but changing everything in one go is a lot fo work.. Anyway, I have one lirbray and that works for a now untill i adapt to the changes.
About the folder created on sd-card: I often make hundreds of versions of a patch before it is finished. Like songs 1, song 2, song 3, etc. and everytime it creates a new folder on the sd card. And if you use tabs you would have to after each save go to card reader mode, copy the tab files, manually to the newly created folder before it works. That would just create a lot of mess of folders on the sd card and also really delay the creational process if you have to do this evrytime for the tabs to work.
Anyway, this is "user input" of how it work in practice. Maybe I have missed a setting for the tabs.
so what your saying is the files are being copied into a directory on the SDCard per patch. if so, then yes, this is the general plan....
the idea is that axoloti will automatically move resources it needs from the computer to the axoloti/sdcard, without the user having to consider the filesystem on the card. one primary motive, so you will never have a patch that doesn't work because its missing a wavetable/sample.
again, like libraries... to do this kind of magic (and alot of other things we want) requires things to be organised, allow axoloti to 'know' about the structure, rather than leaving it to the whim of the user. (look at the Elektron machines, or the Spectralis they use highly structured filesytems for good reasons...)
like libraries, this is a step towards more elaborate things... this is not the end, its a step
I can imagine there is a need for 'shared' resources , we are heading towards packages, so it might be you have a resource package, and then a patch has a dependency on that package - this would be similar to to the Elektron concept of kits, but a bit more 'generic' (a requirement for axoloti given its nature)
so try it, see how you get on... see how things develop... we can't do everything at once, step by step is the only way.
No it does not copy the tab files nor the wave files. The tab files dont work, unless I copy them manually to that folder. That is the issue. The folders created on the Sd-card are just empty. And again. I would have to do that EVERYTIME i save a new version of the song.. Which I do every 2 minuts. Everyone who does works in a "serious" way do this, make a lot of versions. It is just a part of developing.
Like you say it is about progress, but is is also about ease of use and having a nice overview. Copying everything to sd-card that is used in a patch everytime you make a new version of it is not ideal and will make a huge mess on the sd-card. It already has on mine after using only one evening!!!! It would mean hundreds and hundreds of copies of the same files.
To me the idea about the tabs is that I only need ONE copy of them on the sd-card, that I can use on any patch I'd like. I do understand the idea with ease of use by copying everyting you save to the sd-card and I do understand it has positives. I do understand that we need to progress,and I think it is a good idea to be able to save to sd-card, but you should also have the option to use more "general" path for tabs, wavefiles etc. things you use across many patches. There is absolutely no need to make hundreds of copies of each file. You just need 1! Atleast give the user the choice to select if he wants to copy everything to song folder OR it want to use a more general file path.
Maybe something like song versioning should be allowed? For example if a songs main title is Bird, Axoloti then creates a folder for Bird. then you should be allowed, within the same folder be able to make versions, like Bird 1, 2, 3, 4, 5, 6, without Axoloti copy everything(tabs, audio, etc.) to that folder everytime you save a new version. It should only copy to the folder or update it if something have been changed, like for example when new audio files added or new tab files added to that specific song.. Axoloti should ONLY make a folder called bird for the first created song and then ONLY copy new stuff to that folder IF something new is added.
Anyway, I could live with the above, BUT still very important to let the user use a general filepath for stuff you use across many patches. It will quickly become messy with so many copies of the same files. ALso as is now you cannot use the tabs directly from sd-card you have tocopy them, manually, to the song folder. Would be nice to FIRST test what tab youd like and THEN save it to the song folder. Now you basicly have to copy ALL tabs you have to songs folder, select what you need and then remove everyting, except what you are going to use again from the song folder. Not ideal.
So: 1. Versioning of songs within a song folder. 2. Need for a general file path for wav, raw, tab, etc.. VERY VERY important. Could be for checking out what you exactly need BEFORE you copy it to the folder. But it has to be possible to use anything from sd card WITHOUT having to copy it to the song folder.
The general motivation is to have the files that a patch requires on your pc, and Axoloti copying that to sdcard automatically (if it's not present already, or when the file date does not match). That makes patch sharing easier. To avoid a complete mess on the sdcard, a patch runs in a folder on sdcard, so different patches that use files with the same filename for do not start overwriting each others' files.
I understand the regular patch renaming use pattern, but I'd suggest a different way out to avoid the creation of many directories on the sdcard: rather than File->Save as... to a new name, is implementing File->Save copy... to a new name. That will save a (backup) copy of your patch to a new file, but patch opened is still the original filename.
I'm also adding support for files that do not have a master copy on the computer, in that case it will fall back to the (sdcard) path entered in the filename attribute. So you can enter "/root.tab" (will access a file named "root.tab" in the top directory of the sdcard), or "/shared/share.tab" (will access a file named "share.tab" in a directory called "shared").
That would make sense and cover both needs. A key command for it would be nice too
I think that could work easily. Then we would be able to use same filesystem as we have already. That would be really great. Then you would still have the backwards compatibility as well as forward compatibility. I am pretty sure this would cover old users needs, though it would have to be tested.
About the save everything related to a patch to sd-card: Could that be optional? Like something you could switch on/off?
Anyway, I am curious to check if the .tab files will be included when making an embedded object. And .raw files too. Will test this later.
And thank you for listening to an "old" users opinion There is probably also others who use the string index objects in same way to call up .tab files(or what they like to call then) who will probably notice the same issue. But for now I'll jump between 1.06 and 1.08 for making music and for test purposes.
There is no difference the way .tab .raw or .s16 files are handled.
Only "direct filenames" are subject to auto-upload, not in-patch generated filenames like using string/indexed.
Making the creation of a folder for the patch optional? I fear it could add more confusion than it solves any problem. Some patches may also write files to sdcard, and then it's nice too to be able to relate them to the patch that produced it afterwards.
.... This will solve it. If I dont keep the files on the computer itself it will just use the sdcard instead. Basicly use it as it is now. We'll se how it works out.
Running this patch library/demos/synth/mpe got this error error: 'PARAM_INDEX_sub__osc__mix_gain1' was not declared in this scope error: 'PARAM_INDEX_sub__osc__mix_gain1' is not a member of 'rootc::instancesimple__v__1' shell task failed, exit value: 2
then,
Creating patch/patcher, accidentally click update WHILE LIVE, goes like screen shot in and out of LIVE stops producing sound at all?
It doesn't work now. If i write down /root.raw in wave/play fn file input axoloti still looks for this file inside patch directory. And with each lfp/square tick it says: Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw" Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw" Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw" Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw" Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw"
We just talked about this yesterday, so give Johannes a little time to implement it.
But yes, there must be support for how the filesystem work now and it seems like the fallback to sd card idea might be the way to go From what I understand that would work.
WHat happened on this picture is not so hard to work around. Just close tha patch and open in again OR draw the cables again. ANd maybe try and lower voice number after trying the first part.
Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw": Well weird. I dunt understand that. All the -raw files I have tried works fine. But all the -tab files dont work. I think it has to do with how you call the files up on the sd-card. Do you by any chance use string/index for this?
It might not be intended that there is a difference between those filew formats, but there is. Check this patch. In this patch I have a .raw file loaded using a string/c.... Which works perfectly.
BUT when I do the same with the .tab file(which works fine in 1.06) it does NOT work. So there is a difference on how they work. It might not be intended but there is a difference.
I have included the patch AND a .tab file to test with. You probably already have a .raw file so I wont supply that, but I know not many use .tab files. So it is included
Also needs to add to this, that the Sd-card reader mode speed has gone way down. It is now, really, really, really slow. More than before. Takes very long time to copy and delete things form it.
ok, Ive found out whats going on with the first issue, though not quite the cause... and Ive actually seen this a few times now, not just on this patch
@johannes this is fixed by re-saving the sub-patch (warning: don't do this for factory object guys!) we can then diff them and we see:
ok, this is not totally unexpected... so Im not surprised about the fact sha has gone and uuid is there. but what I am surprised about is that the original did not have the UUID...
now obviously, the code is kind of doing the correct thing, its looking up using the name, and if we open in the editor all is well (and hence save is working) BUT it would appear its not totally correct....
my first thought is perhaps its picking up the incorrect version of mix 1g and for some reason, opening in the editor is re-evaluating which object to use, perhaps using type matching?
It should be easy enough to debug, we just need to see when a subpatch is loaded for going live, its not evaluating in the same way as when editing the subpatch.
but slightly concerned there may be deeper issues....
Id say this is show-stopper for release, as I'm assuming it will probably affect many patches, actually Im very surprised we haven't had more testers reporting it, Id say its a pretty common issue.
unfortunately, I don't have time to look at it today, as I'm out all day... and not sure about tomorrow, as things still pretty hectic.
you other issue @keyman ... yeah there are a few things that need to be locked down when live... I guess we need to log it and fix. the case of the UI issue, is it not being able to find the inlet/outlet, the question is why
first of all: Thank you guys for this wonderful Project and Hardware!!!
while testing 1.0.8 on OS X 10.11, I had a freeze after resizing the the "Module Text Editor" Window. I created a module i think it was "sel/sel 4l 16 8t". than i used "edit object definition" after going through the tabs, i resized the object definition window and bam, freeze! i had to hold the power button of my laptop becuse it was totally locked...
Ive just tried to reproduce and it doesn't do it here... (Im using 1.0.8, and OSX 10.11.3)
can you repeatedly get the lock up, or has it just been once?
honestly, I suspect its something else... and this was coincidence. we use java, and its unlikely a UI operation could take down the operating system. personally, Id suspect its more likely hardware related (e.g. usb device conflict or something). probably worth checking in the OSX console and look to see if it reports anything interesting.
thanks for testing. works fine today! I did not had axoloti connected yesterday I was just looking at the new Version without going "live" now I got axoloti connected, it works fine... sorry...
