Axoloti TEST release 1.0.8

#43

It doesn't work now. If i write down /root.raw in wave/play fn file input axoloti still looks for this file inside patch directory. And with each lfp/square tick it says:
Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw"
Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw"
Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw"
Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw"
Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw"

and so on.

It works for table/load -> table/play tho'

#44

We just talked about this yesterday, so give Johannes a little time to implement it.

But yes, there must be support for how the filesystem work now and it seems like the fallback to sd card idea might be the way to go :smile: From what I understand that would work.

WHat happened on this picture is not so hard to work around. Just close tha patch and open in again OR draw the cables again. ANd maybe try and lower voice number after trying the first part.

Axoloti says: file error: FR_NO_FILE, filename:"0:/audiotst/vibez1.raw":
Well weird. I dunt understand that. All the -raw files I have tried works fine. But all the -tab files dont work. I think it has to do with how you call the files up on the sd-card. Do you by any chance use string/index for this?

#45

Nope, i use plain wave/play fn with file input box

#46

IAhh yeah. Cool.

Well yesterday I was using a .raw file and that loaded up perfectly in a table/play. Havent tested the wav player.

@Johannes

It might not be intended that there is a difference between those filew formats, but there is. Check this patch. In this patch I have a .raw file loaded using a string/c.... Which works perfectly.

BUT when I do the same with the .tab file(which works fine in 1.06) it does NOT work. So there is a difference on how they work. It might not be intended but there is a difference.

I have included the patch AND a .tab file to test with. You probably already have a .raw file so I wont supply that, but I know not many use .tab files. So it is included :smile:

Also needs to add to this, that the Sd-card reader mode speed has gone way down. It is now, really, really, really slow. More than before. Takes very long time to copy and delete things form it.

Anyway:
TEST 1.08.axp (5.9 KB)

Link to .tab file:
https://mega.nz/#!uN4zAbzJ!oZ1jiLo0R8sNMr8PqNMRGF4GiOdq7bVigu7Tm-1LM3M

#47

ok, Ive found out whats going on with the first issue, though not quite the cause...
and Ive actually seen this a few times now, not just on this patch

@johannes this is fixed by re-saving the sub-patch (warning: don't do this for factory object guys!)
we can then diff them and we see:

-   <obj type="mix/mix 1 g" sha="9837ebd6f7c0b2b3853ea475d91c943144e2273b" name="sub_osc_mix" x="672" y="70">
+   <obj type="mix/mix 1 g" uuid="e6982841c1bf323ee2062a4b6cc2737adafbd668" name="sub_osc_mix" x="672" y="70">

ok, this is not totally unexpected... so Im not surprised about the fact sha has gone and uuid is there. but what I am surprised about is that the original did not have the UUID...

now obviously, the code is kind of doing the correct thing, its looking up using the name, and if we open in the editor all is well (and hence save is working) BUT it would appear its not totally correct....

my first thought is perhaps its picking up the incorrect version of mix 1g and for some reason, opening in the editor is re-evaluating which object to use, perhaps using type matching?

It should be easy enough to debug, we just need to see when a subpatch is loaded for going live, its not evaluating in the same way as when editing the subpatch.

but slightly concerned there may be deeper issues....

Id say this is show-stopper for release, as I'm assuming it will probably affect many patches,
actually Im very surprised we haven't had more testers reporting it, Id say its a pretty common issue.

unfortunately, I don't have time to look at it today, as I'm out all day... and not sure about tomorrow, as things still pretty hectic.

you other issue @keyman ... yeah there are a few things that need to be locked down when live... I guess we need to log it and fix. the case of the UI issue, is it not being able to find the inlet/outlet, the question is why :smile:

#48

Hi Axos,

first of all: Thank you guys for this wonderful Project and Hardware!!!

while testing 1.0.8 on OS X 10.11, I had a freeze after resizing the the "Module Text Editor" Window.
I created a module i think it was "sel/sel 4l 16 8t". than i used "edit object definition"
after going through the tabs, i resized the object definition window and bam, freeze! i had to hold the power button of my laptop becuse it was totally locked...

cheers,
nico

#49

Ive just tried to reproduce and it doesn't do it here... (Im using 1.0.8, and OSX 10.11.3)

can you repeatedly get the lock up, or has it just been once?

honestly, I suspect its something else... and this was coincidence. we use java, and its unlikely a UI operation could take down the operating system. personally, Id suspect its more likely hardware related (e.g. usb device conflict or something). probably worth checking in the OSX console and look to see if it reports anything interesting.

#50

thanks for testing. works fine today!
I did not had axoloti connected yesterday I was just looking at the new Version without going "live"
now I got axoloti connected, it works fine...
sorry...

#51

@johannes
ok, had a quick look at the above issue...as expected the resolving was done before by SHA.

what I though we needed to do is make resolveType() more intelligent, so rather than fallback purely on name, to actually look at the Nets and then prioritise on types. essentially this would give us 'interface matching'
whilst looking at this , I noticed that this is already done in : PromoteToOverloadedObj()
and this I think is why, when you load up a patch specifically it works, but doesn't appear to work when a subpatch is loaded as part of the parent... so it appears this is probably the way forward to resolve to ensure no patch breaks for 1.0.9
... but probably your going to find the best place to put this , before me :smile:

going forward, we will not have this issue since the resolution should be by UUID which uniquely identifies an object type for life.

#52

Thanks! I was assuming it was falling back to UUID before resolving by name. I'll look into it now.

#53

the particular example I looked at doesn't have uuid in the obj type in the patch... it just had sha and name.

I only looked at the code didnt debug, hence I'm not 100% why the subpatch doesn't have promote called on it, Id assume in a debugger that will become pretty clear... or a little earlier in the evening :smile:

#54

I miss the old way of editing presets, it was very good for editing the sel/objects, although it wasnt good for fader/sel.

#55

Is there a change in editing presets? How exactly? I'm surprised...

#56

before i could see the knobs sel objects, now its only ...

#57

its actually working for knobs, but only if not inside an axs or object, but not for sel and radiobuttons.....

#58

Is the number of presets of that patch (view->settings) configured to more than zero?

#59

Aha! thats it! thank you..makes sense to initialy have all patch settings set to Zero......

#60

Hi,
I cant use presets, the board softlocks when i push one of the buttons i,1,...,8:
Authentic Axoloti Core
Axoloti says: exception: soft watchdog
Axoloti says: pc=0x0
Axoloti says: psr=0x60000000
Axoloti says: lr=0x800D69D
Axoloti says: r12=0xF8B9AC
Axoloti says: cfsr=0x20000
Firmware version: 1.0.0.1, crc=0xA65D81F6, entrypoint=0x20011000

#61

Could you provide me a patch or minimum steps to reproduce this?

#62

I installed 1.0.6 again, and it worked fine.
When I installed 1.0.8 again and started for the first time this happend:
Link to firmware CRC A65D81F6
Status: factory (1.0.8,anon) : OK ( 1.0.8,clean )
Status : home : OK
Status: community (master,anon) : OK ( master,clean )
No available USB device found with matching PID/VID
search path : /home/eric/axoloti/axoloti-factory/objects
search path : /home/eric/axoloti/objects
search path : /home/eric/axoloti/axoloti-contrib/objects
finished loading objects
No available USB device found with matching PID/VID
USB device found
connected
Authentic Axoloti Core
Firmware version: 1.0.0.1, crc=0x38289B65, entrypoint=0x20011000
Firmware CRC mismatch! Please flash the firmware first! Hardware firmware CRC = 38289B65 <> Software CRC = A65D81F6
Link to firmware CRC A65D81F6
Start uploading firmware
firmware file path: /opt/Axoloti/app/firmware/build/axoloti.bin
firmware file size: 591.228
firmware crc: 0xA65D81F6
block uploaded @ 0xC0000000 length 16
block uploaded @ 0xC0000010 length 32768
block uploaded @ 0xC0008010 length 32768
block uploaded @ 0xC0010010 length 32768
block uploaded @ 0xC0018010 length 32768
block uploaded @ 0xC0020010 length 32768
block uploaded @ 0xC0028010 length 32768
block uploaded @ 0xC0030010 length 32768
block uploaded @ 0xC0038010 length 32768
block uploaded @ 0xC0040010 length 32768
block uploaded @ 0xC0048010 length 32768
block uploaded @ 0xC0050010 length 32768
block uploaded @ 0xC0058010 length 32768
block uploaded @ 0xC0060010 length 32768
block uploaded @ 0xC0068010 length 32768
block uploaded @ 0xC0070010 length 32768
block uploaded @ 0xC0078010 length 32768
block uploaded @ 0xC0080010 length 32768
block uploaded @ 0xC0088010 length 32768
block uploaded @ 0xC0090010 length 1404
Done uploading firmware
Start uploading patch
bin path: /opt/Axoloti/app/firmware/flasher/flasher_build/flasher.bin
block uploaded @ 0x20011000 length 15188
Done uploading patch
Start starting patch
**patch start taking too long, disconnecting**
Disconnect request
Done starting patch
USB device found
connected
Authentic Axoloti Core
Firmware version: 1.0.0.1, crc=0xA65D81F6, entrypoint=0x20011000

the error happens with any patch and does not need to be live.