patcher missing labels (dev version)

AlanMJackson 2018-10-19 23:53:08 UTC #1

NOTE: this is for the Experimental branch

Build: 1.0.12-1-432
on Ubuntu 16.04

lokki 2018-10-20 06:48:50 UTC #2

if there is just one inlet/outlet the labels are not displayed. i would call that a feature. not sure, if you mean that though...

jaffasplaffa 2018-10-20 09:17:10 UTC #3

Well in many cases, atleast on the regular version that problem I think can be solved.

If you have added a couple of inlets and named them and the TOP one does not show the name.... Make a new inlet, name it and delete the first one that didnt have a name and replace it with new one. Then update the patcher and I am pretty sure you will get the name for the first inlet too. Atleast this works for objects, but not sure for patch/patcher....

thetechnobear 2018-10-20 09:30:57 UTC #4

It’s by design, as usually for single inlet/outlets it’s obvious due to the nature of the module what it does

It it does often help keep the UI cleaner and easier to read, by making it look a little less fussy.
eg imagine all oscillators having to name its outlet ‘out’ it doesn’t really give us anything

you can still hover over inlet for description
( assuming it’s been filled in )

AlanMJackson 2018-10-25 10:41:07 UTC #5

I agree that's a good design feature if there is only a single inlet / outlet. However this occurs when there are multiple inlets/outlets

thetechnobear 2018-10-25 11:12:54 UTC #6

then thats probably a bug/issue on the experimental branch, as this is not the case on the released version.
sounds like a regression, perhaps something thats still being worked on.

if your not a developer, really you should use the 1.0.12 branch as your base, experimental will have a number of 'oddities', its not supported/nor fully tested as its not meant for end-users.
Im also not sure of its state, and if its really ready for testing or not... it may be something are still 'works in progress'.

If your a developer, of course your help in fixing this kind of issues would be greatly appreciated - communicating via GitHub issues will help, so that you can attach the issue to your fixes when doing a pull request.
(also you can discuss potential fixed with Johannes in advance, check that he is not already doing something in this area)

Mod note: as this is a development release 'issue', Im going to move to developer category and adjust title.

AlanMJackson 2018-10-25 13:06:40 UTC #7

I was going to report this issue in git originally on the experimental branch but the instructions were to report it here instead. I'm happy to do either.

I'm using the experimental branch because I need the USB hub functionality.

I would describe myself as a semi-developer at the moment. I'm competent with python but it's been a fair few years since I did any serious java, so I don't have fixes just yet but I might get the dev environment up and running.

jaffasplaffa 2018-10-25 13:56:23 UTC #8

How does i work?

Didnt try yet...

AlanMJackson 2018-10-25 15:15:05 UTC #9

I plugged in a small 4 port USB hub, and plugged a Novation LaunchControl and QuNexus into the hub, and they can both control the axoloti.

It can be a bit flaky though. Every so often the axoloti might stop seeing the devices but this can be solved by unplugging and re-plugging in the hub to the ax.

thetechnobear 2018-10-25 15:58:48 UTC #10

two things to be aware of with experimental, regarding usb hubs/midi generally

a) unless its changed, its hard coded to just 2 USB devices at the moment

b) all the midi driver code is new, so although we tested it on the controllers we had between us, it may be some controllers might still have issues.
(those around at the beginning of axoloti will remember we had to iron out issues with a few controllers to deal with their quirks)
but i guess it will be useful to know of any issues, though its very difficult to fix, without a developer having access to the controller.

this is why its called experimental