Axoloti TEST release 1.0.10


#19

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


#20

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. :slight_smile: ).

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


#21

Minor problem in object editor: When using the Move up and Move down functions to move attributes around, the description column doesn't follow the currently selected attribute properly. The line it gets moved to has a blank description, and the line it was originally moved from retains the original description, even though it now has a different attribute (the one shifted down as the highlighted one was shifted up).

Haven't checked if this happens to more than attributes.


#22

Bug: the 'Clear' button on the Console window can disappear under some circumstances. I haven't been able to reproduce the exact sequence of events that makes this happen, but it's some combination of clearing the console with the button and/or resizing the Console window.

a|x


#23

Probably not a bug, as such, but maybe just something that's not been thought of yet.

An object that includes external files can be embedded in a patch, but the links to the external files used by the original standalone object then break, because they're now relative to the patch file, rather than the original object.

I'm not sure how/whether this can be fixed automatically, but it can cause problems, as the patch containing the embedded object will then not compile (the now-missing include causes a fatal error). Maybe there could be a warning when embedding the object, with an option to navigate to the required include to re-link it relative to the patch file.

I guess if the Includes pane of the Overview tab in the Object Editor worked, a working path could be entered. At the moment, this pane doesn't get populated from the object XML, even if includes are present, and you can't type in the Includes or Dependencies panes.

Incidentally, what is the suggested use of the Dependencies section of an object's XML definition?

a|x


#24

hmm, i guess the references to the files should carry across the original reference to the library it was taken from.

can you report bugs against 1.0.10... (and ensure bugs are present in 1.0.10), as stated on the 1.0.10 thread, all prior test releases are no longer supported. my mistake i forgot to close this thread.

EDIT: Ive moved you posts to 1.0.10 , so I can close 1.0.9


#25

Sorry about that. I meant to post in the 1.0.10 thread. My bad. I've been using 1.0.10 since it was released.

a|x


#26

no prob, easy to do... as I say I forgot to close it, like I had the other ones.


#27

Possibly. It might have to be converted to an absolute reference, though. Even then, the patch won't be portable between systems, unless the reference is relative to the root of the Axoloti libraries.

I don't know if there has been any discussion on automatically searching specific locations (ie and defined libraries) for any references files.

a|x


#28

as far as i remember there is no code to remove the button, and I cannot reproduce.
its not visible if you make the console window narrow [s], which could be better (by fixing it to right border rather than a fixed position by allowing it a little closer to the connect button)... thats the only way i get it not visible. but perhaps you can find another combo


#29

I'll try to make it happen again.

The button doesn't actually disappear, as such, it just doesn't move back to the left, to remain in view when the window is made narrower.

a|x


#30

Another odd one:

The disp/hex object from the Factory library seems to lose it's label/name sometimes.

I haven't been able to work out exactly when it happens, but if I type a label for it in place of 'hex_', it seems to revert back to the the default name after a while.

If I'm able to reproduce the steps necessary to make it happen, I'll post them here.

The label seems to survive a save/close/reopen of the containing patch, and even closing down the Patcher application and starting it up again, so it's not to do with the value not being saved, more something specific happening that causes the custom label to revert to a default value.

a|x


#31

I haven't been able to make it happen again. I could have noticed the expected behaviour you mentioned, @thetechnobear - i.e. the Clear button disappears if the Console window is too narrow. I'll keep my eye out for it happening again though.

a|x


#32

Another slight niggle with the Object Editor, I'm afraid. Not so much a bug, more a feature that could be confusing (for those as easily confused as me).

The CEntries values are always enclosed within quotes, even though in this case, they're treated as integers within the object.

I should probably shut up for a while, now. I'm making a nuisance of myself :wink:

a|x


#33

I dont think so, you are really good at spotting bugs ....


#34

It's not used anywhere in the code, it's rather experimental. The idea is that objects can declare their dependency on certain platform features. For example Axoloti Core has an sdcard slot and uses the fatfs library to access them. If - somewhere in the future - you'd build a patch (hypothetically!) targeting a VST or AudioUnit, that would not have the fatfs API, so those objects could be excluded from that target profile. Another use case is objects "consuming" a resource that's only available once, so another object requiring the same resource would provoke an error before compiling. But while some objects have some data there it's really not used, and would probably need to be redesigned in some way before it becomes useful.

The CEntries are string substitutions to the object code, so they really are strings, it's the compiler that reads them as numbers, but they really can be anything like complete functions...

You're reporting faster than I'm currently able to address them, please understand my time is very fragmented... Your (and not only yours) reports are certainly useful and appreciated.


#35

I see, thanks very much for the explanations @johannes.

a|x


#36

Sync (pull) FAILED : community (1.0.10,sputnki)
org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files:
objects/hc/osc/beatmachine.axh
org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files:
objects/hc/osc/beatmachine.axh
at org.eclipse.jgit.api.MergeCommand.call(MergeCommand.java:419)
at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:331)
at axoloti.utils.AxoGitLibrary.pull(AxoGitLibrary.java:190)
at axoloti.utils.AxoGitLibrary.sync(AxoGitLibrary.java:105)
at axoloti.menus.FileMenu.jMenuSyncActionPerformed(FileMenu.java:262)
at axoloti.menus.FileMenu.access$400(FileMenu.java:49)
at axoloti.menus.FileMenu$5.actionPerformed(FileMenu.java:132)
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 javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
at java.awt.Component.processMouseEvent(Component.java:6535)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6300)
at java.awt.Container.processEvent(Container.java:2236)
at java.awt.Component.dispatchEventImpl(Component.java:4891)
at java.awt.Container.dispatchEventImpl(Container.java:2294)
at java.awt.Component.dispatchEvent(Component.java:4713)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
at java.awt.Container.dispatchEventImpl(Container.java:2280)
at java.awt.Window.dispatchEventImpl(Window.java:2750)
at java.awt.Component.dispatchEvent(Component.java:4713)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
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)
Caused by: org.eclipse.jgit.errors.CheckoutConflictException: Checkout conflict with files:
objects/hc/osc/beatmachine.axh
at org.eclipse.jgit.dircache.DirCacheCheckout.doCheckout(DirCacheCheckout.java:420)
at org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:402)
at org.eclipse.jgit.api.MergeCommand.call(MergeCommand.java:293)
... 44 more

Something wrong with beatmachine.axh
(i just did a library sinc)


#37

There was a bad push by me last night, but it should have been reverted. Guess you're in the in-between state (maybe synced just at the wrong time yesterday?), backup your own contribs and re-init?


#38

No, i synced 2 minutes prior to the message.

Also, i have to report a bug in the object edrum/bd1.axo (there is a zombie object inside: env/d lin m x which should be replaced with env/d lin m)