Axoloti TEST release 1.0.10

#52

The Axoloti patcher stopped working properly my office iMac yesterday.

Here's the Console window (screenshot taken this morning, the problem first occurred yesterday):

Screen Shot 2016-07-08 at 10.16.08.png1336x1050 60 KB

It seems to stick at this point. Though it is possible to create a new document, I'm not able to make the object browser to appear.

I get this when attempting to open a document from disk.

Axoloti version : 1.0.10-0-gf8ed51d  build time : 10/05/2016 19:56:36 UTC
Link to firmware CRC 3DB31696
Saving preferences...
preferences path : /Users/adrin009/Documents/axoloti/axoloti.prefs
java.lang.NullPointerException
java.lang.NullPointerException
	at axoloti.object.AxoObjectInstanceAbstract.resolveType(AxoObjectInstanceAbstract.java:179)
	at axoloti.Patch.PostContructor(Patch.java:313)
	at axoloti.PatchGUI.PostContructor(PatchGUI.java:817)
	at axoloti.PatchGUI.OpenPatchInvisible(PatchGUI.java:1035)
	at axoloti.PatchGUI.OpenPatch(PatchGUI.java:1054)
	at axoloti.FileUtils.Open(FileUtils.java:149)
	at axoloti.menus.FileMenu.jMenuOpenActionPerformed(FileMenu.java:253)
	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 javax.swing.AbstractButton.doClick(AbstractButton.java:356)
	at javax.swing.plaf.basic.BasicMenuItemUI$Actions.actionPerformed(BasicMenuItemUI.java:802)
	at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1663)
	at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
	at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:699)
	at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:706)
	at javax.swing.JMenuBar.processBindingForKeyStrokeRecursive(JMenuBar.java:706)
	at javax.swing.JMenuBar.processKeyBinding(JMenuBar.java:677)
	at javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:307)
	at javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:293)
	at javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2974)
	at javax.swing.JComponent.processKeyBindings(JComponent.java:2966)
	at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
	at java.awt.Component.processEvent(Component.java:6310)
	at java.awt.Container.processEvent(Container.java:2236)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2294)
	at java.awt.Component.dispatchEvent(Component.java:4711)
	at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)
	at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:806)
	at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1074)
	at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:945)
	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:771)
	at java.awt.Component.dispatchEventImpl(Component.java:4760)
	at java.awt.Container.dispatchEventImpl(Container.java:2294)
	at java.awt.Window.dispatchEventImpl(Window.java:2746)
	at java.awt.Component.dispatchEvent(Component.java:4711)
	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)

I deleted the prefs file, flushed the OS X plist cache, and restarted the Patcher. Seems to work fine now, so I guess the prefs file must have been corrupted somehow.

I can't attach the prefs file, since it's not of one of the allowed types, but here is the content:

<preferences appVersion="1.0.10">
   <CurrentFileDirectory>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/talkie</CurrentFileDirectory>
   <PollInterval>50</PollInterval>
   <MouseDialAngular>false</MouseDialAngular>
   <ExpertMode>false</ExpertMode>
   <recentFiles>
      <string>/Users/adrin009/Documents/axoloti/axoloti-factory/objects/seq/lfsrseq.axh</string>
      <string>/Users/adrin009/Documents/axoloti/axoloti-factory/objects/math/more_math.axh</string>
      <string>/Users/adrin009/Documents/axoloti/axoloti-factory/objects/math/math.axh</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/canto/canto.axh</string>
      <string>/Users/adrin009/Documents/axoloti/axoloti-contrib/patches/jt/grainy-table.axp</string>
      <string>/Users/adrin009/Documents/axoloti/axoloti-contrib/patches/jt/devel/cic_oscillator_workbench.axp</string>
      <string>/Users/adrin009/Desktop/range-test.axp</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/canto/canto_demo.axh</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/canto/canto_demo.axp</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/patches/toneburst/osc/canto_demo.axp</string>
      <string>/Users/adrin009/Documents/axoloti/axoloti-contrib/patches/jt/devel/float_workbench.axp</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/talkie/Talkie Synth.axp</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/talkie/talkie.axh</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/talkie/Talkie Controller.axp</string>
      <string>/Users/adrin009/Documents/axoloti/toneburst.private/objects/toneburst/osc/talkie/talkie 3.axh</string>
      <string>/Users/adrin009/Documents/axoloti/axoloti-contrib/patches/jt/devel/updownsampler_x4.axp</string>
   </recentFiles>
   <RuntimeDir>/Applications/axoloti_runtime</RuntimeDir>
   <FirmwareDir>/Applications/Axoloti.app/Contents/Java/firmware</FirmwareDir>
   <FavouriteDir></FavouriteDir>
   <ControllerObject></ControllerObject>
   <ControllerEnabled>false</ControllerEnabled>
   <gitlib>
      <Id>factory</Id>
      <Type>git</Type>
      <LocalLocation>/Users/adrin009/Documents/axoloti/axoloti-factory/</LocalLocation>
      <Enabled>true</Enabled>
      <RemoteLocation>https://github.com/axoloti/axoloti-factory.git</RemoteLocation>
      <UserId></UserId>
      <Password></Password>
      <AutoSync>false</AutoSync>
      <Revision></Revision>
      <ContributorPrefix></ContributorPrefix>
   </gitlib>
   <filelib>
      <Id>home</Id>
      <Type>local</Type>
      <LocalLocation>/Users/adrin009/Documents/axoloti/</LocalLocation>
      <Enabled>true</Enabled>
      <RemoteLocation></RemoteLocation>
      <UserId></UserId>
      <Password></Password>
      <AutoSync>false</AutoSync>
      <Revision></Revision>
      <ContributorPrefix></ContributorPrefix>
   </filelib>
   <gitlib>
      <Id>community</Id>
      <Type>git</Type>
      <LocalLocation>/Users/adrin009/Documents/axoloti/axoloti-contrib/</LocalLocation>
      <Enabled>true</Enabled>
      <RemoteLocation>https://github.com/axoloti/axoloti-contrib.git</RemoteLocation>
      <UserId>toneburst</UserId>
      <Password>REDACTED</Password>
      <AutoSync>false</AutoSync>
      <Revision></Revision>
      <ContributorPrefix>toneburst</ContributorPrefix>
   </gitlib>
   <gitlib>
      <Id>toneburst.Private</Id>
      <Type>git</Type>
      <LocalLocation>/Users/adrin009/Documents/axoloti/toneburst.private/</LocalLocation>
      <Enabled>true</Enabled>
      <RemoteLocation>https://github.com/toneburst/axoloti</RemoteLocation>
      <UserId>toneburst</UserId>
      <Password>REDACTED</Password>
      <AutoSync>true</AutoSync>
      <Revision></Revision>
      <ContributorPrefix>toneburst</ContributorPrefix>
   </gitlib>
</preferences>

Incidentally, I notice the GitHub password for any user repos is stored in plaintext in the prefs file (that's not my actual password, above). Not sure this is a good thing...

a|x

#53

Just noticed the plain password as well today. Filed an issue on github: https://github.com/axoloti/axoloti/issues/322

#54

The user password for Github? That is really not good...

#55

lol, Im surprised its taken this long for someone to notice and comment on the password, I expected it to happen when it was first released :slight_smile:

the reason, is obvious, there is quite a dev effort required for a decent solution, the obvious solutions don't really achieve any more security:

a) ask user for password each time
this is trivial, and could be done optionally... but is pretty tedious for users, and doesn't work when you do a sync on startup.
b) encrypt password
pointless, the source code is open source, it would take 2 minutes to decode the password, regardless of encryption.
c) certificates
don't actually the solve the issue discussed here, they solve a different (albeit valid) issue.
if you have a certificate stored on your computer, this also can be used to gain access to your github account... unless you password protect it, then we are back to, what to do with that password , see a and b.

so I guess we could put these in place, but I think they are half hearted at best, certainly a and b are 'easy' - certificates, need a reasonable amount of development to make them useable by non-techies, which is #1 priority.

there are other more appropriate solution, some of them are specific to a platform (e.g. mac keychains), some are specific to a host (e.g. github application access)

have I missed another possibility? or idea? does anyone want to look into this?

workaround: theoretically, I think any (technical) user can workaround this already. simply establish your credentials with github via certs etc, and then clone the community repo, and don't put in your username and password. the clone establishes your authorisation, so there is no need to use a username/password. (your prefix is still needed)

#56

I have to report a minor issue in midi/out/clock @johannes
In krate code, lines 10 and 11 the attributes MIDI_START and MIDI_CONTINUE should be switched.

This would be the correct code:

  if (_pos24ppq)     MidiSend1((midi_device_t) attr_device, MIDI_START);
  else     MidiSend1((midi_device_t) attr_device, MIDI_CONTINUE);

Now the code is not correct: if you stop and reset the clock and then restart a midi continue message is sent, and external devices will continue playing from where they stopped (which is not what you want if you reset the clock)

#57

I cannot compile this in opensuse leap 42.1 I was able to compile 1.0.9 before.
Any ideas? Thank you.

[...]
Making all in src
make[2]: Entering directory '/home/gabriel/axoloti/platform_linux/src/dfu-util-0.8/src'
CC main.o
In file included from main.c:34:0:
portable.h:17:17: fatal error: io.h: No such file or directory
# include
^
compilation terminated.
Makefile:330: recipe for target 'main.o' failed
make[2]: *** [main.o] Error 1
make[2]: Leaving directory '/home/gabriel/axoloti/platform_linux/src/dfu-util-0.8/src'
Makefile:289: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/gabriel/axoloti/platform_linux/src/dfu-util-0.8'
Makefile:229: recipe for target 'all' failed
make: *** [all] Error 2

#58

Most odd. I tried several times to compile it as root and it would fail with the error above. Tried again, as user and it would not do it, but when I tried once more as root it succeeded...

#59

2 posts were split to a new topic: Kernel Panic OSX - El Capitan

#61

It doesn't sound like excuses at all, and as you say, it's entirely possible the crashes weren't directly related to the Axoloti patcher or Core.

I've heard from other sources that there were changes in USB device support in El Cap.

I will try the tests you suggest, and let you know what I find.

a|x

#62

4 posts were merged into an existing topic: Improvements/Wishes for the patcher

#66

Ooops, yes, sorry. Not so much a bug, more of a feature-request, I suppose.
Could you possibly move my posts to there? If not, I will do it myself by copy-paste.

a|x

#67

Scrub that, what you wrote in that thread pretty-much covers it, I think.

having said that, I do consider the hidden folders showing at / a bug.

a|x

#68

No problem.
Ive already added a post which i think mind of covers it, also with a user link to apples recommendations.

in a similar vain, I think we need to be careful with bugs, that are not specific to 1.0.10.
(my intention for this thread was mainly for issues we have introduced in 1.010, by new features etc)

my concern, is no one has the time to trawl various threads, in particular long ones like this, and once this is closed it will likely be forgotten.

for existing bugs, they probable should dedicated helpdesk threads ... and we probably need to get these bugs into github issues.... its not practical to track bugs here.

basically, if its unclear if its a bug, vs user error, or feature request, raise it here to be discussed...
if not then i think it needs to go directly in github issues so it can be tracked.

#69

Sorry...... :wink: ..............

#70

It's hard to know if a bug was introduced in a new software version, though. It could easily be that it was there before, but you never stumbled across it because you'd never gone through that exact sequence of actions previously.

a|x

#71

yeah, I know , usually its about... has this area of functionality changed? (which we do try to list)

with 1.0.10 you are able to keep multiple copies of axoloti on your computer, so you can actually run 1.0.6 and 1.0.10 and see if its existing in 1.0.6. of course this assumes you can reproduce reliably and easily, but going thru that step is useful for devs anyway, as they need to be able to reproduce.

honestly, though with 1.0.10 its not a big deal, as I think most 'heavy' users are now on 1.0.10, so its almost 'defacto' released. its not ideal from a software engineering viewpoint, but its proven pretty tricky to get out the release, the longer the test has gone on, the more features were 'added' whilst we fixed 'critical bugs' and this formed a vicious circle, which unfortunately we have not quite broken free of yet.
which is why I'm kind of trying to separate stuff out into this release, and after.

unfortunately, Ive seen this on many open source projects, you get into a cycle, when there a perpetual unstable/beta/alpha release that everyone uses, since the last official release is years old. Its not healthy, as it kind of then mean half finished features and bugs are 'tolerated', since its an 'unstable/dev release' - and eventually, there are so many unfinished things, it actually becomes impossible to ever put out a proper release again :frowning:
hence why I'm keen to break the cycle

#72

This is most likely caused by an incomplete download/extract. The installer downloads a few zips/tgz's, and if the file already exists, it skips the download, when it is incomplete, extraction will fail. Likewise, when the extracted folder corresponding to the download already exists, it skips extracting all files again.
Compiling as root is not needed, and could cause permission issues if you try compiling without root permissions again.

#73

Yes, that looks correct, I have pushed this to axoloti-factory, sync libraries and the fix will be fetched.

#74

Thanks, for the followup. However in opensuse, I have never been able to compile as a user. I have to modify the build file (as I posted some time ago), and there is something else (is it the UPD rules?) that fails as well.
You are right that some files ownership needs to be changed so it can be run by the user.

#75