Axoloti TEST release 1.0.9


#1

Prerelease

This release may contain showstopper bugs! Only use this if you have the patience to report bugs. To report bugs in this prerelease, reply in this thread! Patches saved in this version will not work with versions prior to this release

Available at https://github.com/axoloti/axoloti/releases/tag/1.0.9

This replaces 1.0.8 which is no longer supported
replaced by 1.0.10 - Available at https://github.com/axoloti/axoloti/releases/tag/1.0.10

this version will no longer work with the community library

as always we thank you for your help in testing.

Note: I hope this is a release candidate i.e. if there are no major issues then it will become the release version.
This also means that only major bugs will be addressed in this release. (stability is the most important aspect here)

as issues were found, there will likely be a release for testing these issues are resolved.
It would be appreciated, if you could spend some time on 1.0.9 to ensure there are no other issues, before we release 1.010.

Installation

  • backup your patches! (once saved in 1.0.9 you will not be able to open in 1.0.6!)
  • (optionally... backup you axoloti home directory)
  • Install as normal from above
  • The runtimes have not changed, no need to re-install that part
  • when started use 'sync libraries' to move factory to new 1.0.9 version
    (you can see this is done with Sync Successful : factory (1.0.9,anon) )
  • your sub-patches may need to be upgrade (see below)

Changes compared to test release 1.0.8

  • Improved - fallback for SD Card file loading
  • Fix - modulations in poly patches
  • Fix - various object editor issues
  • Improved -object editor add to library (replaces save as)
  • Fix/Improved - object editor workflow
  • Fix - windows when reinitialising libraries
  • Improved/Fix - mid device detection on midi host port
  • Improved - objects now have a unique id (uuid) which is unrelated to name, and sha type is no longer used.
  • Improved - disable update patch/patcher when patch is live
  • Fix - various other issues/improvements, see logs for details

some thing to particularly test/re-try

  • midi devices that were not being detected correctly
  • using the object editor, please check the whole workflow
  • embedded objects e.g. to create variations of factory objects

Upgrading sub-patches

important note regarding community library

again, I remind you , backup you patches before doing this!

There have been some small changes, which mean that patches with sub-patches may not compile, if you open and save them , then re-open, they will fix themselves :wink:

If you have a lot of patches that need upgrading you can do this on the command line with
./Axoloti.sh -runUpgrade

you may still need to do a couple manually, but it worked for all patches in the tutorial/demos except 2, so good chance it will work for most of your patches :wink:

Troubleshooting

  • please report bugs as per reporting guidelines, giving as many details as possible, including any messages present in the console. also please try to reproduce the issue.

  • if you have troubles the 'fail safe' is

    • backup your patches/objects and your axoloti home directory including preferences you can re-test later if needed.
    • if issues with libraries, try preferences->init libraries
    • delete your axoloti.prefs file
    • if that doesn't work, try deleting your axoloti home directory (this will re-download the libraries)

Known issues (unresolved)

Known issues (fixed in development)

  • 'zombie' objects cannot be replaced. (workaround: needs to be deleted, then new object added)
  • converting a subpatch into an embedded object will render patch corrupt
    (workaround: don't do it :wink:)
  • embedded subpatch , save option should not be available (only apply/add to lib)
  • error when saving objects with no description
  • apply a change to an object whilst live renders patch corrupt/display issue, should not be a allowed to edit, whilst live (workaround: don't do it) - fix, user is no longer able to take a patch live, whilst the object editor is open with a patcher/object

Limitations

  • limitations on parameter types for object editor, and cannot set optional attributes (eg. max/min)
    (currently consider this as unsupported for this release)

Change logs

changes since last test release (1.0.8)
changes since release (1.0.6)


#2

SUPER YIHAAAAAA :smile:

THANKS

Al ready downloading :smile:


#3

Community Library

Note: I have NOT upgraded the community library sub-patches. as I think this has to be down to individual contributors. this is because of the potential of us both making changes, and potentially cause merge conflicts. (generally, I believe the contributor retains ownership/maintenance duties)

also currently we do not version the community library, it would be trivial to do,
BUT has again, the potential of introducing conflicts, or contributors updating the wrong version, and id have to occasionally merge changes across... something Id only be willing to do for a short while (and occasionally) as its a manual process.

I do suspect as the library grows, and more released versions of axoloti are in the wild this may be reviewed, so that we can prune the library of 'defunct' objects

open to discussion... but I think for now its best, thoughts?

note: most user libraries don't do version management... other than say, which version an patch/object works on


#4

Ok I got it installed :smile: Great

And I am now testing the "fallback to sd-card" and I am not sure if I am doing it right, cause I cant get it to work. When I try to use the string/index for calling up .raw files I am getting the same error as in 1.08:

Axoloti says: file error: FR_NO_PATH, filename:"0:/1Cycle Wt/inlet_filename"

Do I have to set up something in the patch for this to work? Or in the preferences?

Thanks


#5

ok, this is not something I've used, or tested....

but I've just checked the code:
no preferences etc.. this is all on the board
I think the file is references from the root of the SD card.
file references by default are from patch directory on the SD card, you can prefix with / to make it from the root.

as for your error, that look problematic, e.g. inlet_filename sounds like its not using a proper filename, rather generating a patch with the inlet name. bug in table/load error reporting, now fixed in factory lib.

double check a couple of things:
a) it should have updated your firmware when you first connected.
b) you did do a sync libraries after you installed.

if you want me to test it, your going to have to send me a patch, and also the relevant wav/raw files, as I don't have time to start creating these to test it.

EDIT: (after testing)
inlet_filename - small reporting bug in table/load, now fixed in update factory lib
files are considered to be from the patch directory on the sdcard
e.g. wt/256/000.raw , refers to /mypatch/wt/256/000.raw
if you want it on the root, you have to be explicit, and use the root directory
e.g. /wt/256/000.raw , refers to /wt/256/000.raw


#6

Coll thanks for quick reply:

I just created a new patch and pasted the Wavetable patcher object into it and now I get this error:
Axoloti says: file error: FR_NO_PATH, filename:"0:/untitled/inlet_filename"

Which to me makes it look like that Axoloti is still expecting the files to be in the patch folder. The patch is called "untitled" hence Axoloti looks in "untitled" folder. And before this(first example provided above) the patch was called "1Cycle Wt". So still looking in patch folder, I am pretty sure.

I have updated firmware. Axoloti requested for the update and it did all the flashing, etc.
The firmware ID is:
AE85D426
5V: 4.99V VDD:3.29V

Yes I did that also.

Just trying to figure out how it works. I am totally OK with having to do some adjustments to current set up. That is no problem add all, I just need to know what I need to adjust. And thanks for helping finding out :wink:

Here is the patch example:
TB WT Example.axp (7.8 KB)

And here are the waves to go with the patch, 32 1cycle waves:
https://mega.nz/#!SdoxnQpJ!iLVORuT3ZJELcGDcC3tOMYEN1LFWELNJdjVePnf_ht0

Sorry for the weird name. It because of encryption codes from Mega.nz page...

Unzip & copy the "Wt" folder to root of sd card to have same set up as me for testing.

Also if you dont have Alex's "phasor compl GC" object installed, just change it to"phasor compl".


#7

Wave names are saved in this list:
https://mega.nz/#!2B4FyLoY!wwY8MBoZvhlT8iA2NU0AVYb9ImmQsxEmr33naqICw9Y

I dont remember exactly where I got the waves from. Aq waves or something like that. Not adventure kid.


#8

Ok, first, next time, I want a cut down example patch , with the wave tables, all in a single zip file from dropbox
the mega.nz file was garbage, and your patch used objects I dont have
I dont have the time to mess about with this kind of thing.
(no more mega.nz, drop box is free... and you can share links, use it so I dont have this nonsense)

please I spend time looking at your issues, so I think its completely fair that you make my life super easy, I want a one click install, super obvious example.... sure, you have to spend 5 mins to prepare it, but thats 5 minutes less I have to spend in addition to the 5-10mins i need to spend anyway!

anyway, good news is its working fine....

so the error message was bogus, just a bug in reporting the filename in table/load which Ive now fixed, and pushed the factory 1.0.9 library (sync library time!)

also, your patch is incorrect, if you wish to use the root directory then you need to prefix with

/Wt/256/

this means to use the root directory, Wt/256 means to base it from the current patch directory.

with that it appears to work

( I couldn't test the waves switching, as I didnt have the waves, but with dummy files it worked fine)


#9

I thought I didt make it easy. I put exacty what to do: change the object to phasor compl. I only noticed that object after i uploaded them. So instead of uploading it again, I posted the info. Anyway, sorry and thanks....

And the waves was a present for you and the community..... which I spend time making also.....

What was wrong with the file? I have never had any problem with Mega.nz? Just redownloaded them, they unzip fine here. And all of the wavetables are in 1 file. You should just copy the folder to sd-card as I described?

It is prefixed with exactly what you wrote? See picture? Or do you mean the patch has to be in same directory as the waves? which is kind if what I am trying to avoid. The wavetables should be able to be called up from any patch, that was the idea with implementing "fallback to sd-card", as I have understood from Johannes comments on it.

Do you mean that there is a / missing? It used to work with out in old version, anyway... I have added the / now.

Well, that was the main issue I presented. It doesnt switch between waves, when using the wave nr. knob....WHen moving thew knob yuo get the above errors..


#10

I got the zip file, but in then unzipped to some cgzip file or some other odd file extension.
your patch referred to obj/osc/phasor compl GC, which neither exists as a factory or a community object.
(i dont make this stuff up, if I say it doesnt work, it doesnt work)

the deal is simple, this is why NOT to use a more involved patch, for this 'bug' all I need is a knob connected to string/indexed and table/load... I dont care about the rest.... thats for you to debug your patch, not me :wink:

yes it has to be
/Wt/256/

I didn't need a knob to change values... even on startup, it tried to load 004.raw
so I know since I changed that it works... if it changes based on the knob, only relates to how your patch works.

again, back to simple patch, with associated files in a single zip, on drop = no messing, and I can help you faster...
(simple patch = only using objects that are completely relevant, and preferably only from the factory- I dont need things to make a sound - just illustrate the error)

can't say didn't use it, but I will say...
now, patches are run in a subdirectory (a patch directory), so they are not in the root (so perhaps thats your difference) and its 'normal file syntax' that without a path prefix like '/', this means the current directory. so these two things combined, means its logical now. (i.e. Id not consider it a bug, or a behaviour Id want to change, regardless of previous behaviour)


#11

I do appreciated you helping out, but I supplied info about how to make it work. Just change the object to phasor/compl and copy the folder to Sd-card. Pretty easy and simple.

Well, my patch works perfectly fine in 1.06......... So, no need for troubleshooting, but thanks. I am just asking nicely about how to make this work in 1.09..... There are some things that dont add up, cause it still gives same error as 1.08!

And problem is that sometimes when it get "involved" there are complications, so yes, complicated patches are need sometimes to present a certain issue.

Anyway, I have just made a new simpler set up and it still doesnt work, subpatch or not:
Wt2.axp (2.0 KB)

Since you got it working, could you post the patch that works as an example?

Thanks


#12

AND a dropbox link for the wavetables:

https://www.dropbox.com/s/f0yq2znd8w03c2d/Wt.zip?dl=0


#13

thanks... now that works (simple :wink:)

jtest.axp (7.5 KB)

(I disconnected one audio outlet, TSR cable which i usually use in balanced mode i.e. not relevant)

from your screenshot, id check you dont have a space at the front of the prefix, I cant tell for sure, but it looks like it.
you'll also note, axoloti is helpfully pointing out its an invalid filename NOT that the file cannot be found.
(also its showing you the file its trying to look for, which already looks suspicious!)


#14

I got it sorted now. I reinstalled 1.09, synced again then it worked. And I also added the / in the beginning of the prefix. This was not necessary in old versions. I have always used these patches without. But nice to know it is necessary for new version

Thank you for the effort.

Stil dont understand what the issue with Mega is though. It works fine here. Dropbox is no good IMO, cause you have very limited space. Mega gives 50 gigs also for free. Much better than Dropbox. WHat tool did you use to unzip?


#15

reinstalling it was not necessary
it was the space at the front, on your last example ... I know this, as I retested my version of the patch with the space, and got exactly the same error as you. so simple typo, nothing more sinister than that.

anyway, glad your up and running, enjoy.


#16

Yes it had something to do with / and the space probably also. I pasted the name again from another patch that I knew worked and added the /.. then it worked.


#17

Just a quick question. I was on 1.0.8, so cd ~/axoloti and issued a "git pull". This downloaded something, but after building it still was 1.0.8. I then got rid of the whole /axoloti folder and cloned it again (everything went fine). I guess that this is a last resort way of upgrading, but not particularly efficient. Is there an easier way upgrade via git?


#18

Is there an easier way upgrade via git?

  • why not just upgrade by copying 1.09 to applications folder? That worked here :smile:

#19

Because I am on opensuse linux and there is not installation rpm for it, so I have no other choice than recompiling the source.


#20

I suspect you didnt pull the tags

git pull --tags or git fetch --tags

the version number is generated by looking at the git tags and then compiled into version.java

so your pull would have updated the code, just you didnt see the new tags, and so it just reported the wrong version
(we use it for reporting, and also defaulting which version of the factory objects to use, as these are on a version branch)

(clone brings down the current tags)

you can see tags you have currently with
git tag -l