I've been through far too many reinstalls of the app and the libraries (not through any fault of Axoloti) to remember how paths were entered. However, I always specify the full path if entering anything manually unless I explicitly want relative ones, so could the non "C:" prefixed ones be from 1.0.6? Oh well, doesn't really matter to me, we're on 1.0.9 and all is well!
BTW, while playing with axoloti.prefs I had to set < ExpertMode > to true - how could I not! - which gave me a "Test Compilation" entry in the file menu. Selecting that item didn't appear to do anything off the bat (yes, I will press the Red Button if there is one, it's a compulsion that will probably be the end of me one day ).
I don't migrate paths from 1.0.6, as far as I can remember (was a long time ago , I did that ) I'm pretty sure, it has to be an entered path... and I've not had other reports of it. will keep it in mind, if it comes up again.
I'll check, I usually use this from the command line, .. so might be gui menu item is broken...basically its suppose to try to compile all the demo/tutorial patches... so I know that they compile before we release. (but as you can imagine, its easier for me to do this on the command line, where I can capture the output etc)
Although I'm getting old enough that I'm most likely past my cognitive peak, I can assure you that I do not enter paths like that, and if there's a browse/select box I always use it. The only path I entered manually in conjunction with Axoloti, is the one for the control object which has the "C:" of course. Having been through what is probably an unusual high amount of permutations of Axoloti 1.0.6. - 1.0.9 installs (installed, messed up, fixed, installed again etc..), I leave room for something not of my doing to have happened. Anyway, that part of my report is obviously useless, and I don't care how it happened. I only care that, if nothing else, I still have the wherewithal to enter full paths
except the known issues listed below, are there any other issues any one has found? (compared to functionality in 1.0.6)
I think I've resolved the known issues... so I really want to get this closed off, and hopefully one final release candidate, for testing these limited areas.
as you can appreciate, only when this is released as a stable version for all users, are we able to start work on new features and enhancements... hopefully an incentive for us all to get this tested and released
I am very happy with 1.09. All patches I tried opening have worked. Much better than 1.08. So I am more than happy to move on to 1.09 and have all ready made the change fully. Not going back to 1.06 again.
Only small things, like the issues I mentioned that sometimes a k-rate mixer is loaded instead of an s-rate mixer. That issue I tried to reproduce, but when I saved the patch and closed and reopened it again to send to you, the mixer was an s-rate mixer, as supposed. And it happens only to some patches, not all. Anyway, I can live with that. I changed the mixer and didnt see the problem again.
For my sake you can make 1.09 official and start focusing on other stuff
Maybe some FFT objects, IIR objects for convolution? Filters that goes above 12khz. Would be awesome with focus on creating some new exciting new obects
Thanks to Axoloti crew for working hard on this update
Not sure if this is related to 1.0.9 really, but when you add a spinner attribute, how do you set the min/max values from the UI? I've ended up editing the XML file for the object directly.
lets say its a missing feature you can add any extra information about parameters, attributes or displays which means some cannot be created. ... but it will be added, and we obviously know its missing.
however, I still use the editor for basic object creation, I just supplement it with a good xml editor, for adding the extras.
Just downloaded the latest development version, I've noticed that now when I go live, if there are any patch editors open a dialog box comes up asking me to close them. I assume this was done because sometimes the changes weren't saved properly prior to starting the patch? It wasn't like this previously.
It seems to save my current edit state (which item in the object editor that was open, location within the code editor, etc) when clicking the edit button in the patch/object object, but not when selecting 'edit object definition' from the object's own menu (I then get the default view which oftentimes needs to be resized to be useful for code editing).
Also, I'm not 100% sure, but it seems that if I edit an embedded object using the 'edit object definition' item in the object's own menu, the changes aren't always in fact made to the object. Sometimes when I re-edit the object my changes have been lost. Sometimes when i close the object editor i get the question "Do you want to save changes? (yes/no/cancel), both when clicking to close the window or pressing ALT-F4, and sometimes not. When using the edit button in the object itself it seems to work fine though.
yes, Im not sure I entirely follow your comments, but basically I think this is correct...
yes, I changed it so that editors have to be closed, before going live - as editing whilst live was corrupting patches. (as I mentioned before, doing anything else was problematic)
yes, editing an embedded object, does not need 'saving' as it is part of the patch, so its editing in place, but I think it needs to be 'applied' and you should get a warning as such when you close the object.
editing via object definition , changes need saving as you are editing a copy, it should print up a dialog to ask to save if necessary. (or add to library if its a factory object, which is 'read only')
(don't know about the sizing, i didnt touch that)
I do suspect there could be an inconsistency with using edit object definition, when a patch object... the issue is its a bit unclear the intended action ... are you trying to edit the instance in the patch, or the patch/object itself... I think, I assume the later (so consistent with other objects) but its likely that user expects the former.
There could be issues with the above , it was a reasonably big change... since originally the editor was working on the in-memory object, this caused huge inconsistencies and potential problems, e.g. you could save over a factory object, or be editing just in memory... so the patch works, but next time you opened the patch, you had the previous behaviour as the object has never been saved. so I had to move to a model where you edit a copy, so its clear you need to save, and that its impossible to overwrite (in memory or to disk) a factory object....
this obviously means slight 'usage differences', and its possible the confirmation to save/apply its not popping up every time it should. (though i obviously did test it, but possibly missing a field or two)
Hi I'm having trouble working further on a patch, it won't open anymore This is what axoloti spits out:
Saving preferences... preferences path : /Users/Simon/Documents/axoloti/axoloti.prefs 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 77 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 77 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$Injector.read(Composite.java:1433) 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.Variable$Adapter.read(Variable.java:482) at org.simpleframework.xml.core.Composite.readVariable(Composite.java:613) 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'm not sure I've described it very well either ... and I haven't tested it that extensively either ...
Perhaps another solution would be to make all the patch editors go 'read only' while a patch was live, i.e. you couldn't make any changes but could still look around?
I did a simple test of just adding a line to the k-rate code.
If I click the edit button in the patch/object object, I don't get any dialog when i close the edit window, but when I open it again (either by clicking edit or by selecting 'edit object definition') the changes are still there, and are included when I compile the patch.
If I choose 'edit object definition' in the object context menu, I still don't get any dialog when closing after making changes, and the Save entry in the File menu of the object editor is greyed out. When reopening the object editor, either via the context menu or the edit button, the changes i made have been lost. However, if I click Apply in the File menu after making the changes and then close the object editor, I get a dialog saying 'Unsaved changes, do you want to apply? (yes/no/cancel)', however, if I click Yes here, the changes I made are then only visible if I reopen the editor via 'edit object definiton', not via the edit button.
It seems to me that when editing a patch/object object, there would and could only be one possible instance of it, embedded in the patch. There might be multiple patch/object objects in the patch, but each one would be different (haven't tried this though). But perhaps I'm misunderstanding how it's supposed to work.
Unfortunate , the editors have no link to the patchers, nor any concept of them going live - I could inform via the link but, I'd then have to implement a read only mode, and also I'm not 100% sure that the corruption wouldn't happen if the editor was returned after the patch came back from live. Really this was a band aid fix , since we need to get out of this test cycle.
I'll take a look at the edit va edit definition, for perhaps just use the edit button on the patch/object
I'm tempted to remove either the edit button or edit definition option for this object as it's clearly a duplication.
One advantage to the 'need to close' thing is that previously I sometimes ended up with a couple of editors for the same object (not because of a bug but because I'd forgotten I already had one open!) which got really confusing after a while.
To my mind it would seem that both the 'edit object definition' and the edit button should have the same functionality at least. And the edit button is a handy shortcut and a visual hint that the object is in fact embedded and not part of a library. So my vote would be to keep both, but have them do the same thing.
yeah, the close object editor thing may be reviewed/improved in another release. my main priority is to ensure we don't end up with corrupt patches/unsaved changes etc, as thats understandably very annoying for everyone.
yes, Ive made edit and edit object definition, do the same thing... which is to edit your instance of the object, which, I agree, I think is what most want/expect.
Ive think I've found and resolved most of the issues you mention, lots of different things - missing fields checks, and needing you to move focus off a field were main culprits. but to fix, Ive gone for a new approach, which checks the if the generated xml would change. Ive also made alot of changes around ensuring, changes are only applied if you ask for them to be... there were a few inconsistencies. unfortunately this has highlighted another issue with the editor used for inlets/outlets etc... so we need to resolve this before, I can push this to the dev repo.
anyway, its looking better much better, thanks for the report. I'll let you know when the new version is checked-in, and perhaps you can have another play with it if/when you get time.
sorry, didn't see this due to other 'events', distracting me.
its a known issue (see top post) ... and its already fixed... you can actually edit the patch xml, and fix it
If you PM me the patch, I can do this for you... and also then describe exactly what needs to be done. Ive done this before, but I can remember the exact change I had to make,I think it was adding a description field (as the error implies) .. but id prefer to double check.
for now if you embed an object, or save your own objects - make sure you add a description field. (and to be extra sure, tab off the field to another field, again this bug will be resolved in next release)
in the next version the description field is optional, so will read the 'corrupt' patch, and also wont require a description.
EDIT: this will happen each time you create a new patch/object. (or convert and embed existing object)
you can stop the description error, by ensuring you enter a description for the patch/object you create, but the other error cannot be avoided... you will have to edit the AXP file to fix it.
until of course the next release where this is fixed.
(fyi, for others not following thread .. these are in development, not in 1.0.9. then will be in the next release)
I did some work on this today and yesterday which has now been merged into development.
I tried quite a few things, and now seem to be better there are 2 known issues...
the tabs when shown on the patch/object are sometimes shown as disabled(?), they aren't and still work, so its a UI thing. (tried a few things to solve, its a bit weird, its not focus... and same code path for when its right and wrong)
when you edit an object, and save/apply , the object in the patch is not immediately updating... you need to use the object browser to replace it. (it should be shown correctly there) ... this is a bit odd, the patch has been told its changed, so not sure if its ignoring it, or just not repainting.
obviously the latter, is more important...
apart from that, saves/apply seemed to be applied correctly, as does saying no to changes. and the whole confirmation code is improved - there were quite a few changes to get to this state though, so its possible I've missed something
).
) 
This is what axoloti spits out: