Axoloti TEST release 1.0.10

[johannes]

Discontinued/Unsupported

this is now replaced by the official 1.0.11 release see here

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

This replaces 1.0.9 which is no longer supported

As always we thank you for your help in testing.

Note: This is a release candidate i.e. if there are no major issues then it will become the next (non-test) release version.
This also means that only major bugs will be addressed in this release.

Installation

• backup your patches! (once saved in 1.0.10 you will not be able to open in 1.0.9!)
• (optionally... backup you axoloti home directory)
• contributors, read post below about committing changes before upgrading
• 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.10 version
  (you can see this is done with Sync Successful : factory (1.0.10,anon) )
• your sub-patches may need to be upgrade (see below)

Changes compared to test release 1.0.9

• Improved USB-Midi controller compatibility
• Firmware CRC was not matching between pc/mac/linux of the same release
• Improved object editor
• Added linked file subpatches to "patch/patcher" embedded objects (in object menu "embed as patch/patcher")
• Much less likely to lose connection when starting a patch that uses over 100% load
• And more:
• Full list of changes: 1.0.9...1.0.10

[thetechnobear]

a couple of important notes:

Contributors to the community library
Thank you
From this release, contributions are uploaded to a specific release.
So, if you upload with 1.0.9, it will not be available in 1.0.10, until I merge it across, which will be done periodically. - I'll do this regularly initially, and then less frequently as we move forward.

My suggestion is contributors therefore move as soon as possible, and this will be a useful way to get your users to move forward to.

as for upgrading, my suggestion is:

• finish any outstanding work on 1.0.9, and then synchronise your library to upload it
• upgrade to 1.0.10, and do sync libraries to move to 1.0.10 (or you can run 1.0.10 alongside to 1.0.9, see below).

note: if you do this, you will NOT see your changes in 1.0.10 immediately.
wait until I merge them... do not start editing the object in 1.0.10, until you see the latest changes are reflected in 1.0.10 when you do sync libs, and do not copy your changes from 1.0.9. if you dom you will cause a merge conflict the next time I do a merge of others 1.0.9 changes, which I will have to resolve manually.
... and then possible later conflicts on your own repo when you next sync, which will cause you grief, you have been warned

the alternative, if you want to see you changes immediately, or carry on working in the object, is to move your changes to one side, upgrade to 1.0.10, then move them back. i.e. make the changes on 1.0.10 and not 1.0.10

a couple of additional notes:

• we will only merge 'forward' i.e. 1.0.9 to 1.0.10 never 1.0.10 to 1.0.9
• please do NOT edit/copy changes between versions yourself, wait for the merge, doing so could possibly cause merge conflicts, which I will have to manually resolve, which in turn could cause additional issues.
• when we make the 'production release' this will have a new version number, and we will do the same process - these test branches will become redundant, and in particular the master branch (used pre 1.0.10) will be 'repurposed' (I'll probably branch it first, to make 1.0.9 branch for posterity.

please also read this post about issues I'm seeing so far

Running multiple versions of Axoloti
Axoloti now supports 'versioned home directories', this means you can run different versions of Axoloti, side by side.
by default, axoloti will look for its home directory in ~/Documents/axoloti ( and the windows equivalent)
BUT if you have a version specific home directory it will use that instead, for 1.0.10 the version directory would be called:
~/Documents/axoloti_1_0_10 (again, similar on windows)

Ive found this useful for testing out new releases, whilst having the 'stable' one around for use.

Notes:

• On the Mac, when I install Axoloti I simply rename the application e.g. call it Axoloti-1.0.10
• On windows, the installer will automatically overwrite the old axoloti app, so the approach on windows is to rename the 'old' version before you install the new version.
• currently the runtime is compatible with new and old versions so no extra steps are required, but this can be set in preferences if they diverged (unlikely!)
• the version directory, is derived from the version compiled into the app (as noted in the about box etc), it is unrelated to the application name, which you can call what you like.

[philoop]

yeah !!! my old corrupted patches load again!!!

[toneburst]

I'm getting this graphic glitch with the object editor (highlighted tab appears with grey instead of blue background, making white text hard to read).

It doesn't happen all the time, and I haven't managed to work out how to reproduce it, mainly because I've been working on stuff, and don't know when the glitch first appeared.

There's nothing in the log that seems to be related.

I'll try and reproduce it.

UPDATE:
Just closing and reopening the object editor using the Edit button on the embedded object seems to cause the above to happen.

I'm using a Macbook Pro
MacOS X 10.11.x (El Capitan)
Java Version.. not sure, will check when back home

a|x

[toneburst]

I also get this (same embedded object).

You can see there are graphic glitches in the 'type' column, and 'illegal access' in the 'Value' column below (two unrelated issues I imagine).

I'm attaching the patch I've been working on below. The object I've been editing is the one named 'Interpolation'.

a|x

Kick Interpolation.axp (5.7 KB)

[thetechnobear]

Contributors only
when you do the upgrade, can you please note down the exact steps you use for upgrading....

Ive seen now a couple of examples where upgrading users have left the library in a incorrect state.
in particular

• merge conflicts due to changes in both 1.0.9 and 1.0.10
• 1.0.10 changes on the 1.0.9 branch

for this release this its not a big issue, as its 'testing' only and the 1.0.9 branch will die, but I need to get a handle on what is going wrong... e.g. is the workflow I described wrong, or are users not following it, or is there some other bug?
but I can only do this, if i know what steps users are following... (much better than me guessing/assuming what they did)

Ive a solution in mind, based on what I think is happening, if it is part of the upgrade process...

also a note... if I see changes on both the old version and new version, then I will use the new version only.
Its expected you are only editing on the latest version, not on multiple versions.

here are the scenarios
changes in 1.0.10 (only) - applied to 1.0.10 only (preferred)
changes in 1.0.9 (only) - applied immediately to 1.0.9, then merged to 1.0.10 (periodically, about 1/day)
changes in 1.0.9 and 1.0.10, applied to 1.0.10 and 1.0.9 immediately, then merged to 1.0.10 (periodically) can cause issues that need intervention, and so is 'frowned' upon! , and conflicts in 1.0.10 will be resolved by using the 1.0.10 changes only

[thetechnobear]

thanks @toneburst

the menu one i knew about, as you pointed out, its to do with using the edit button or menu... and then some oddity with 'focus management', but the workarounds i tried, either had nasty side effects or didn't work around.
I have to same Im actually tempted to say we should remove the "edit" button, I know its handy, but it also takes up object UI space.... thoughts? @johannes

the other one, yes, is related to type... not had a chance to look at the cause yet
(I though I also saw it throwing an error in the console too, which is annoying )

for reference, we also know there is still an issue with cursor disappearing, seems to be mainly if using a trackpad.

Im also seeing corruption when cutting and pasting in the one-liner scripts, though I think this is not new.

[toneburst]

Another thing I've noticed still seems to happen (and again is related to that pesky edit button on an embedded patch/object).

I can still press the 'edit' button when the patch is live. Doing so produces this kind of graphic screwup, and the object I attempted to edit seems to stop working, too.

It doesn't seem to happen every time, and since starting this post, I haven't been able to reproduce the problem, but it has happened several times.

a|x

[johannes]

confirmed...
You can delete the zombie nets by right-clicking on a connected inlet/outlet and select delete net

[toneburst]

That's good to know. Last time this happened, though, the object I had (foolishly) tried to edit while the patch was live also stopped working after that. I quit the patcher without saving, and it was OK when reopened.

I guess the edit button needs to be disabled when the patch is live.

a|x

[toneburst]

I'm getting the 'zombie nets' again. This time, it seems to happen whenever I hit the edit button on the embedded patch/object in the attached .axp.

It seemed to happen after I had attempted to edit the Description in the first tab of the object editor.

I originally used the env/decay object from the factory library as the basis for my embedded custom object, and I think it was after I attempted to edit the object Description text in the object editor that the zombie connections started to appear.

After supposedly saving/applying the changes to the object code, the original text 'decay envelope' reappeared, the next time I invoked the object editor.

Now, when I hit the edit button on the patch/object, I get the phantom dashed net appearing.

On this occasion, the patch was not live.

Nothing in the log.

a|x

Kick Interpolation.axp (6.3 KB)

[toneburst]

There's another weird thing related to the object editor, I'm afraid.

I've managed to get the updated patch/object Description to 'stick' now, after several attempts, and now I don't get the zombie connections when editing.

Now I've noticed something else happening.

If I copy-paste the object in question, then try and edit the copied object (using either method of invoking the editor), I get the original description text 'decay envelope' again, despite the fact that the object I copied this new one from had the updated text.

The patch, and the patcher application itself has been closed and reopened several times since I started working on my custom object.

a|x

[thetechnobear]

the patch is 'corrupt' ... try this one.
Kick Interpolation.axp (5.9 KB)

whats happened is the Interpolation objects has nets that are incomplete... did you save the patch after editing it when it was live?

the issue is we need to find how the patch got into this state.

[thetechnobear]

If I copy-paste the object in question, then try and edit the copied object (using either method of invoking the editor), I get the original description text 'decay envelope' again, despite the fact that the object I copied this new one from had the updated text.

yeah, something odd going on with description... i can see it being edited as well, but its not being saved when you save the patch... (which probably explains why the copy is like this too)
however, if i change the author it appears ok...

EDIT: ok, found, I just forgot to update the description in one place.. fixed in dev

[toneburst]

did you save the patch after editing it when it was live?

I may have... But if I did, it's likely others will do the same thing, equally inadvertently.

a|x

[thetechnobear]

No doubt ...I'm trying to determine the cause.

[Jan]

Ive seen now a couple of examples where upgrading users have left the library in a incorrect state.in particular

merge conflicts due to changes in both 1.0.9 and 1.0.10
1.0.10 changes on the 1.0.9 branch

for this release this its not a big issue, as its 'testing' only and the 1.0.9 branch will die, but I need to get a handle on what is going wrong... e.g. is the workflow I described wrong, or are users not following it, or is there some other bug?

I have to admit, at first I was a bit confused about this upgrade procedure. Because for me the standard procedure would be:

• I have no outstanding work on my contributions.
• Therefore I don't have to upload changes on the old branch (e.g. 1.0.9)
• So there is no need to merge

Also, if I would upload changes to 1.0.9, there are at least three possible reasons:

• I finished my outstanding work before upgrading to 1.0.10
• The upload was a mistake
• It's a bugfix.

Merging makes only sense for the first scenario. And I guess the third scenario will become relevant - e.g.with a stable release most people are using and some newer test releases. So maybe it would be better if contributors would have to post a merge request (as with the contributor access).

By the way - I think your 'merging service' is very generous. Thanks a lot @thetechnobear

[thetechnobear]

@jan, partly this release is about seeing 'how it goes', with the liberty we are afforded because the 'official release' will be the first one with the libraries... i.e. the test branches are not required.

theres a few approaches we can take for the future, and I think we should discuss these in the 'object lifecycle' thread,
... Ive pretty much decided after this release, I'll look into using a 'stash' and upgrade approach, which mean users wont really be required to do anything, it'll 'just work' ... but this doesn't answer the question of 'maintenance/support' of old versions which some users may be using for performance. (again something Ive raised in the 'object lifecycle' thread.

anyway, I'll monitor how things go... I suspect many contributors will have upgraded this weekend, in which case, if its just a couple of cases of issues, then actually thats not that bad.

[toneburst]

Another object editor glitch.

If I delete an int 32 parameter, the minValue and maxValue properties in the lower panel remain, which seems a bit odd, since they no longer relate to anything.

a|x

[ricard]

Just downloaded the latest dev. Really pleased that the properties for applicable attributes can now be edited directly in the object editor. Thanks @johannes or @thetechnobear (couldn't find who was responsible for this particular item during a quick git history search... at any rate thanks to you both for the work you put into this so that we ordinary users can just ride the waves. ).

Haven't done any extensive testing, but I'll report stuff as it comes up. (I haven't had time for an Axoloti fun for a couple of weeks now but trying to get back to it).

One thing I've noticed though is that with a patch/object patch, clicking the edit button in the object doesn't always open the object editor. I can't remember that happening before. I can't find anything specific that causes it, what seems to help is clicking on another window that happens to be open on my desktop, it can be an Axoloti window or not. If I find a clearer pattern I'll report it. (Running Axoloti on Debian Jessie).