Axoloti TEST release 1.0.8

#32

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.

sdfdsfsdf.png891x465 40.5 KB

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.

#33

not true, you can have as many as you like.
you just need to make sure you give them unique names.... in your example you left all the details blank.

#34

Yes you are right :smile: Sorry. Think its late. Time to go to bed and give it a rest. Didnt think about the naming thing :smile:

But would really like to get @johannes input on the sd-card and tab issue.

#35

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 :smile:

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.

Sample Folder Structure
#36

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.

#37

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").

Would that fit your workflow?

Sample Folder Structure
#39

That would make sense and cover both needs. A key command for it would be nice too :wink:

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 :wink: 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.

#40

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.

#41

Well as I understand it:

.... 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.

#42

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?

#43

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"

and so on.

It works for table/load -> table/play tho'

#44

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 :smile: 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?

#45

Nope, i use plain wave/play fn with file input box

#46

IAhh yeah. Cool.

Well yesterday I was using a .raw file and that loaded up perfectly in a table/play. Havent tested the wav player.

@Johannes

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 :smile:

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.

Anyway:
TEST 1.08.axp (5.9 KB)

Link to .tab file:
https://mega.nz/#!uN4zAbzJ!oZ1jiLo0R8sNMr8PqNMRGF4GiOdq7bVigu7Tm-1LM3M

#47

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:

-   <obj type="mix/mix 1 g" sha="9837ebd6f7c0b2b3853ea475d91c943144e2273b" name="sub_osc_mix" x="672" y="70">
+   <obj type="mix/mix 1 g" uuid="e6982841c1bf323ee2062a4b6cc2737adafbd668" name="sub_osc_mix" x="672" y="70">

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 :smile:

#48

Hi Axos,

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...

cheers,
nico

#49

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.

#50

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...

#51

@johannes
ok, had a quick look at the above issue...as expected the resolving was done before by SHA.

what I though we needed to do is make resolveType() more intelligent, so rather than fallback purely on name, to actually look at the Nets and then prioritise on types. essentially this would give us 'interface matching'
whilst looking at this , I noticed that this is already done in : PromoteToOverloadedObj()
and this I think is why, when you load up a patch specifically it works, but doesn't appear to work when a subpatch is loaded as part of the parent... so it appears this is probably the way forward to resolve to ensure no patch breaks for 1.0.9
... but probably your going to find the best place to put this , before me :smile:

going forward, we will not have this issue since the resolution should be by UUID which uniquely identifies an object type for life.

#52

Thanks! I was assuming it was falling back to UUID before resolving by name. I'll look into it now.