Axoloti TEST release 1.0.9

anon5189335 · 2016-04-10 18:48:06 UTC

Ah yes. But problem is if it is an object with parameters, the parameter settings are lost.

Anyway, seems like technobear took note of it, so it will probably be fixed soon

anon5189335 · 2016-04-10 18:49:43 UTC

Ah yeah, will try that tommorow. But not sure if parameter settings will there this way.

Thanks

thetechnobear · 2016-04-10 18:57:34 UTC

its fixed in dev ... but unlikely it will be released "soon".
my personal opinion, is we will need to wait with 1.0.9 a while, to see if anything else crops up that urgently needs fixing, before this can be turned into a 'full release'.
so the more you guys test over the next few days/week, the more confident we will be to make that release ... so get patching

anon5189335 · 2016-04-10 19:13:58 UTC

Yay, on it here Testing a lot of patches to see if there are comaptiblity issues.

A lot of the patches I have opened have worked. That was not the case in 1.08. So pretty positive here

But those with red objects does not work yet. I think i'll pull a version from github to get this working tommorow.

toneburst · 2016-04-10 21:18:43 UTC

I think embedded patcher objects are still buggy in 1.0.9. I'm getting the same errors as I did in 1.0.8 now (and lost work again, annoyingly).

I now get the following when I try to open an .axp file I saved with an embedded patcher object:

org.simpleframework.xml.core.ValueRequiredException: Empty value for @org.simpleframework.xml.Element(name=, type=void, data=false, required=true) on field 'sDescription' public java.lang.String axoloti.object.AxoObjectAbstract.sDescription in class axoloti.object.AxoObject at line 9
org.simpleframework.xml.core.ValueRequiredException: Empty value for @org.simpleframework.xml.Element(name=, type=void, data=false, required=true) on field 'sDescription' public java.lang.String axoloti.object.AxoObjectAbstract.sDescription in class axoloti.object.AxoObject at line 9
	at org.simpleframework.xml.core.Composite.readInstance(Composite.java:580)
	at org.simpleframework.xml.core.Composite.readUnion(Composite.java:549)
	at org.simpleframework.xml.core.Composite.readElement(Composite.java:532)
	at org.simpleframework.xml.core.Composite.readElements(Composite.java:445)
	at org.simpleframework.xml.core.Composite.access$400(Composite.java:59)
	at org.simpleframework.xml.core.Composite$Builder.read(Composite.java:1383)
	at org.simpleframework.xml.core.Composite.read(Composite.java:201)
	at org.simpleframework.xml.core.Composite.read(Composite.java:148)
	at org.simpleframework.xml.core.Composite.readVariable(Composite.java:623)
	at org.simpleframework.xml.core.Composite.readInstance(Composite.java:573)
	at org.simpleframework.xml.core.Composite.readUnion(Composite.java:549)
	at org.simpleframework.xml.core.Composite.readElement(Composite.java:532)
	at org.simpleframework.xml.core.Composite.readElements(Composite.java:445)
	at org.simpleframework.xml.core.Composite.access$400(Composite.java:59)
	at org.simpleframework.xml.core.Composite$Builder.read(Composite.java:1383)
	at org.simpleframework.xml.core.Composite.read(Composite.java:201)
	at org.simpleframework.xml.core.Composite.read(Composite.java:148)
	at org.simpleframework.xml.core.Traverser.read(Traverser.java:92)
	at org.simpleframework.xml.core.CompositeInlineList.read(CompositeInlineList.java:190)
	at org.simpleframework.xml.core.CompositeInlineList.read(CompositeInlineList.java:167)
	at org.simpleframework.xml.core.CompositeInlineList.read(CompositeInlineList.java:144)
	at org.simpleframework.xml.core.CompositeListUnion.readElement(CompositeListUnion.java:189)
	at org.simpleframework.xml.core.CompositeListUnion.read(CompositeListUnion.java:162)
	at org.simpleframework.xml.core.Composite.readVariable(Composite.java:619)
	at org.simpleframework.xml.core.Composite.readInstance(Composite.java:573)
	at org.simpleframework.xml.core.Composite.readUnion(Composite.java:549)
	at org.simpleframework.xml.core.Composite.readElement(Composite.java:532)
	at org.simpleframework.xml.core.Composite.readElements(Composite.java:445)
	at org.simpleframework.xml.core.Composite.access$400(Composite.java:59)
	at org.simpleframework.xml.core.Composite$Builder.read(Composite.java:1383)
	at org.simpleframework.xml.core.Composite.read(Composite.java:201)
	at org.simpleframework.xml.core.Composite.read(Composite.java:148)
	at org.simpleframework.xml.core.Traverser.read(Traverser.java:92)
	at org.simpleframework.xml.core.Persister.read(Persister.java:625)
	at org.simpleframework.xml.core.Persister.read(Persister.java:606)
	at org.simpleframework.xml.core.Persister.read(Persister.java:584)
	at org.simpleframework.xml.core.Persister.read(Persister.java:543)
	at org.simpleframework.xml.core.Persister.read(Persister.java:521)
	at org.simpleframework.xml.core.Persister.read(Persister.java:426)
	at axoloti.PatchGUI.OpenPatchInvisible(PatchGUI.java:1029)
	at axoloti.PatchGUI.OpenPatch(PatchGUI.java:1042)
	at axoloti.FileUtils.Open(FileUtils.java:149)
	at axoloti.menus.FileMenu.jMenuOpenActionPerformed(FileMenu.java:251)
	at axoloti.menus.FileMenu.access$200(FileMenu.java:49)
	at axoloti.menus.FileMenu$3.actionPerformed(FileMenu.java:105)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
	at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
	at com.apple.laf.ScreenMenuItem.actionPerformed(ScreenMenuItem.java:125)
	at java.awt.MenuItem.processActionEvent(MenuItem.java:669)
	at java.awt.MenuItem.processEvent(MenuItem.java:628)
	at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:351)
	at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:339)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:761)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.awt.EventQueue$4.run(EventQueue.java:731)
	at java.awt.EventQueue$4.run(EventQueue.java:729)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

I had previously saved the file and managed to reopen it. On the last occasion before it screwed up again, the patcher object wasn't working as expected (green cable to disp/i object was showing as dashed and the expected output was not being displayed by the display object), but was compiling without error. On saving, and attempting to reopen the file, it failed with the error above.

The sub-patch was created originally from a Factory object. I was editing it using the builtin
a|x

thetechnobear · 2016-04-10 21:47:05 UTC

please next time, I need reproducible steps, what exactly did you go leading up to the error.
and you should attempt to repeat, the same thing, and see if it happens again.
(the above just test me what error you got, and what happened next... nothing about which objects you edited, what you changed)

ok, so given zero information, about what you did... what it looks like to me, is that you removed the description.... and this is invalid, many of the fields you see on the object have to have values.
(yes, I know the editor should enforce it, if I get time I'll look into fixing it.. its getting pretty lonely here... we need more developers helping out - hint hint!)

do I know this is what you did, no of course, not... but given, what you provided, thats thing i can currently come up with and reproduce.

I don't have any clue how you got into this state, its just not enough information....

philoop · 2016-04-10 21:56:48 UTC

I have seen this java error very often ! Embeding works fine .... until I try embedding 2 delays wich renders the patches unloadable.This happend on different patches, and as the delays always were the last embedded i could never finish a patch ready to upload.
i.e https://sebiik.github.io/community.axoloti.com.backup/uploads/default/original/2X/8/8879639aa29dce89715d398ef319ab42c7647de5.axp

toneburst · 2016-04-10 22:17:20 UTC

I think there may be two different things going on. Both could be considered user-error, but should still not cause file-corruption.

I was getting confused about the difference between the 'Save' and 'Apply' items in the File menu, when editing the embedded patcher/object.
After I'd realised I should Apply the changes to the patch/object, I realised I was sometimes attempting to Apply the edits while the patch was live. That's when the below happened (and is repeatable)

If the file is saved while in the above state, it seems to become corrupt. I wasn't able to reproduce the error above, and I have been able to reopen the file, on this occasion (after retrieving an old version from the GitHub history), but as detailed below, it's still become corrupt.

I've attached the file I've been working on.

So, to reproduce the error, try:

open the file below
click the edit button
make the patch live
hit Apply from the File menu

That should cause the graphic bug above.

If you 'unlive' the patch and save it now, when the patch is reopened, the graphic glitch will have gone, but the green cable connecting the two objects will be dashed and the disp/i object will not receive a value from object_1.

Furthermore, disconnecting and reconnecting the cable will not fix the problem.

I'm on a MacBook Pro
MacOS X 10.11.3
Java build 1.8.0 73-b02
a|x

triggerman-test.axp (3.1 KB)

thetechnobear · 2016-04-10 23:25:13 UTC

which delay object ?
stomp/delay is a subpatch and cannot be converted like this, in fact the convert to embedded object, should be convert to embedded patch (not sure why its not!)

sounds like you have the error often, so you should be able to give me exact steps to reproduce, no?

thetechnobear · 2016-04-10 23:49:45 UTC

you should not be applying changes while a patch is live...
(really the bug here, is that the entire UI should be locked down when live, but currently it doesnt track all open windows, so thats virtually impossible... )
this is probably putting the path in an undefined state.

is this the what you did previously to 'corrupt' the file?
(actually all you need to do to recover it, is to manually edit it and add a description field to the offending object)

apply vs save

apply is for embedded objects
save, should be only for non embedded object (so seems like a bug for it to not be disabled)
if you want to convert an embedded object to a file based object, then you use 'add to library'

the reason you are seeing the above error is clear from the error message ...

    org.simpleframework.xml.core.ValueRequiredException: Empty value for @org.simpleframework.xml.Element(name=, type=void, data=false, required=true) on field 'sDescription' public java.lang.String axoloti.object.AxoObjectAbstract.sDescription in class axoloti.object.AxoObject at line 9

or to paraphrase, Empty value for sDescription....
you will, I suspect, see that in each case when your seeting this, if edit the object, the description field will be blank. currently, the only way I can reproduce this, is to attempt to convert to an object, an object that is in fact as subpatch. (as I said in the above post this seems like a bug, it should be convert to embedded patcher)

I suspect there are a few edge cases, that need to be resolved... hence why its very important to know exactly how you get into these situations.

btw: posting patch files are they are 'corrupted' is not much help, its what you did (exactly) before you hit save.... the error message already tells use whats wrong, what it does tell us, is how we got to that state.

philoop · 2016-04-11 09:34:09 UTC

ok checked again ..embedding 1 delay is enough to render my patch unloadable.
The delay i used is /phi/delay/ECHO1Y
the message
org.simpleframework.xml.core.ValueRequiredException: Empty value for @org.simpleframework.xml.Element(name=, type=void, data=false, required=true) on field 'sDescription' public java.lang.String axoloti.object.AxoObjectAbstract.sDescription in class axoloti.object.AxoObject at line 23

line 19-23:
obj type="filter/lp m" sha="c2224dc682842eae1af4496f3f94a6afc1525ee4" uuid="1aa1bc51da479ed92429af700591f9d7b9f45f22" name="HP IN" x="224" y="112">
params>
frac32.s.map name="pitch" onParent="true" value="64.0"/>
frac32.u.map name="reso" value="0.0"/>
/params>

(i had to remove some characters to make it postable.
it would be good if posting code would be easier)

thetechnobear · 2016-04-11 10:25:40 UTC

you need to indent the lines with 4 spaces e.g.

this.is_code_it*can&have#any@character+=you±want

(please read the markup language guide about posts)

sub patches cannot be converted to an object using "convert to embedded object"....
... im not sure how this got broken, or if this is just a change in naming (should be convert to embedded patcher), but as I repeatedly said above... the issue is, when its converting, the description field is left blank, this needs to be filled in with something, before you save the patch.

(p.s. the line 23, does not refer to the patch file... thats irrelevant, it refers to the line of code in AxoObject.java which causes the issue... which we already know what it is, it will be where it deserialises the AxoObject)

philoop · 2016-04-11 10:37:55 UTC

I only embeded the delay as a patcher. ...luckily due to uploading the Delay to contributions, i dont have to embed anymore ! I now only have to clean my patches from not working versions....and i am lucky to finally found out what was going wrong always.

thetechnobear · 2016-04-11 11:34:45 UTC

are you saying you didn't use the convert to embedded object on /phi/delay/ECHO1Y ?
Ive no idea what this means....what are you exactly doing.

please everyone (this is not directed at you Phil) give me a list of exact steps of how to reproduce problems...
e.g.
Im using Mac OSX 10.11.4 , Axoloti 1.0.9
console say "....."
steps to reproduce:
create new patch
add ./objects/phi/delay/ECHO1Y to patch
select ECHO1Y, then choose convert to embeded object
save patch
load patch will now fail...

generally, Im not going to follow up on any more issues, where the report does not include
- platform (window/mac) and operating system version.
- axoloti version number
- errors/warnings in console
- a complete list of steps which can reproduce the error
(if I follow your lists of steps and the error does not occur, then I will again ignore the issue)

Im not going to do this chasing any more... Im fed up appearing as the ogre, asking for more and more information. if you don't supply it, then I wont look to fix this issue - simple

sorry, I know, you guys are trying to do the best you can, and I do appreciate the reports... but they just don't contain what I need, and this means I have to do a lot of legwork, and make many assumptions about what you are doing....
Im not paid to do this, its not may day job... i don't have the time, and frankly its 'not fun' ... and unless i start making it fun again (for me), I will simply stop doing it

philoop · 2016-04-11 13:31:29 UTC

well no ...I used the convert to embedded patcher/object.
Anyway its only with this ECHO1Y.axs, and we dont need to investigate further......
Solution found ..dont embedd ECHO1Y.axs

philoop · 2016-04-11 15:00:00 UTC

I think there is some confusion about embedd as a patcher or embedd as an object.
(just look at our discusion today..)
In 1.0.8 i was able to choose wether to embedd as patcher or as an object.

thetechnobear · 2016-04-11 16:55:36 UTC

I know... thats why i said....

I don't know if johannes changed this deliberately (and its just a bugged implementation) or its a bug introduced due to some other change. I need to go through the code and possibly change logs to check which... (as it possibly has a big influence on how I go about fixing it)

thetechnobear · 2016-04-15 17:52:46 UTC

Ok, Ive fixed (in dev) " converting a subpatch into an embedded object will render patch corrupt"

from the code, the intended behaviour, is that this should become patcher/objects as well.
this means if you want a AXS object to be embedded as a patch/patcher, you should simply create a patcher/patch and copy its contents to it.

It would be useful for those that can build from github to test this 'embed to patch object' in as many ways as possible,
I've obviously tested the simple use cases (obj->emb axs->emb) , compiles, saves, loads... but it needs more thorough testings. (which I dont have time to do)

@johannes
(the main issue, was cloning the object, will still retain its type, in this case AxoObjectFromPatcher, so I now create a new AxoObject, and copy the appropriate data across.)

one thing... I think in the future this could be enhanced (I had a quick attempt but got into some issues).
I think if your are embedding a subpatch, it should become a patcher/patch, with a copy of the patch...
the reason being, it becomes impossible for end users to really edit these, patcher/objects - well at least its not user friendly. perhaps its nice to have a convert to patcher/object as well.
(bizarrely this is what i thought used to be the case, but at least since 1.0.6 this has not been the case... so perhaps prior to that?)

anon5189335 · 2016-04-15 17:59:46 UTC

Sorry for noob question, but what does:

actually mean?

Thanks

thetechnobear · 2016-04-15 18:08:11 UTC

'in development' environment
specifically, it means I've committed it to my own github repository and issued a pull request (to the main axoloti repo).

at some point (usually fairly quickly) Johannes will then 'accept the pull request' and merge it into the main axoloi repo.(you can see on the main axoloti repo, if this has been done yet or not)

at this point anyone building against the master branch of axoloti will see (and be able to test) the change.

then much later when Johannes considers its ready, a release will be made, which is a binary build for users to install.