How do I make my own GUI controls for the patcher?, or modify/extend existing ones

#1

I'm starting to get to grips with the patcher and finding I would like some controls that don't exist as yet.

I have some coding experience and would like to try and modify and extend the functionality of some of the existing controls and create new controls

Here are a couple of my ideas so far.

Rotary controllers that can have an upper and lower limit set and a way of dividing that range into steps if needed.
A way of having it display text labels instead of numbers would also be very useful, would take up much less space that the existing horizontal and vertical selectors, which btw would be good to have labels for the options in as well.

How would I begin to get to grips with the code so I can start trying make new controls, and other modules?

#2

the gui controls are interfacing to 'patch' parameters.
if you wanted to add your own or change their behaviour, you will need to change the UI which is written in Java - you can do this, by forking the Axoloti repository, and then using the build scripts.
(fyi: we use netbeans for the dialogs/menus etc)

if you come up with something you believe is useful for others, you can use github to issue a pull request.

generally Id say this is more an 'open source' development task, rather than something to be done for a specific user project, as there are quite a few elements involved. but thats just my opinion, others may feel differently.

#3

Hey @strum,

My advice would be to check out a copy of the code from Github and look at an existing component like the dial (DialComponent.java) and where it is used (ParameterInstanceFrac32UMap.java, look at the supertypes of this as well). Then proceed from there up to the object types (specifically AxoObjectInstance) and look at how a particular object uses such a parameter, osc/sin for example. This will give you a sense of how the Patch is modeled and how data flows in the UI.

Netbeans is convenient, but isn't a strict requirement. You really only need it to edit the .form layouts that define various window and dialogs layouts. The Patch UI elements are in general just rendered with basic Swing component code; you don't need to edit the .form files to work on these. Netbeans makes building easier though; you can also just build from the command line with ant if you prefer that.

Feel free to ping me if you need specific help with anything or want me to take a look at some code.

Best,
Nicolas

#4

Yep that sounds like the way to go, thanks.
Hoping to get time to start looking at code in the next week or so.
Busy with hardware ATM.

I can see that an software emulator would be very useful.

I wonder if there is already an ST32 development emulator available?

Know of anything like that?

#5

I don't off the top of my head. If I recall correctly, Johannes uses in-circuit debugging via an Eclipse plugin. If you happen to have a stm32f4discovery board, it includes the STLINK hardware that allows you to program and debug other ST chips (there are standalone STLINKs as well if you want to go that route). I have a discovery board lying around, but I haven't had time to get it all going yet; I've been working on other stuff. I'll try to put up some notes once I get around to playing with it.

What hardware stuff are you working on?

#6

I'll have a look for STM32 emulators later on tonight, I can imagine it would save a lot of time and wear and tear on the board plugging it in and out all the time.

STM32 seems to be become something of a standard development platform for all sorts of microcontroller applications and it would be worthwhile me getting a dev board and learning the tools to develop my own apps, and/or write custom firmware for Axoloti.

As for hardware, firstly I want to make a 3U eurorack mounting panel with some rotary encoders, a display and a bunch of jack sockets for clock/gate/cv ins and outs to control, and be controlled by other synth modules.

It needs some pre-amps for the audio ins and outs to buffer higher level signals into and out of it. so I wanted to build them, isn't there a second channel on the audio codec chip? Breaking that out with a pre-amp could be very useful.

Once I get it mounted in the panel I'll solder some headers to the board and develop a breakout board to sit on the headers with the buffers, power regulator, pre amps, display driver if needed, encoder driver, etc.

#7

GUI controls with a user adjustable range: this has a deep impact since it will affect GUI, firmware data structures, document format, and perhaps also the usb protocol. This modification is on my wishlist too, and plan to do this as part of a bigger code refactor.

I have not tried software emulation, there is one integrated in the eclipse gnu-arm plugins. To be really useful, emulating the firmware will also require to simulate IO, codec interrupts, usb, sdcard... This is where it becomes difficult I believe.

#8

you can use an STLINK/SWD with Axoloti as well, you will need to solder a header on JP1
see this link : https://sebiik.github.io/community.axoloti.com.backup/t/low-level-firmware-debugging-via-swd/275

#9

well it still only puts out an integer, can't see why that would be so difficult or need change of any of the lower level stuff, but without knowing the code I'll just have to take your word for it.

Found the GNU ARM STM32 stuff for QEMU, looks like that could be the core of an emulator, but as you say the other things will be needed to make it fully functional.

All in good time I guess, when I get the board mounted in a rack and make some preamps for it I'll get deeper into the software and hopefully become a useful contributor in time.

With the power of a 32bit 128Mhz cpu almost anything is possible.

#10

As I want a 'better' looking GUI too, I started to play with the DialComponent first. I implemented a way to load images for each dial position and found a quite easy way to do it. The dial is rendered by Knobman and loaded once for for all dials in an array. At run time, an index is calculated (from the value) to get the appropriate image, which is displayed. The animation is smooth.

dial.png966x553 31.7 KB
. I'll do this for every dynamic component (switches, buttons and whatever). If you think, I'm on the right track, I'll put it into the repository. Feedback is welcome.

#11

YAY @DragonSF :slight_smile:

Looks pretty great, a bit big though, but that is just my silly opinion.... Keep going :slight_smile:

#12

Smaller is possible, but doesn't look good. I can experiment with different sizes though.

#13

Sorry, I'm reluctant to integrate such changes, current graphics are made out of scaleable vector primitives, even though scaling is not currently implemented, I believe scaleability will become important in future development. Bitmaps will become ugly when scaled.
Apart from technical concerns, I'm not quite sure if this sort of GUI benefits from a visual style where everything looks "plausibly mechanical". For instance, currently you can "focus" one parameter, and then navigate through parameters by pressing tab and shift-tab. Focus is currently indicated by thick lines, and is quite standard GUI behavior, not sure how to represent this in a plausibly mechanical-looking knob. I see the benefits of led-rings around real encoder-knobs, but not for an on-screen parameter dial. Next, do we need to simulate the look of LCD's, nixie tubes, engraving, or Dymo tape for every text label? :slight_smile:

#14

In a way, I understand what you are up to. What I really would like to have, is a surface panel, where all the relevant controls can be collected and behave the same as the corresponding control in the patch. In the surface panel, the size of a control can be as big as necessary, but as everything is in one place, you have a good overview over all parameters. And another nice to have, is to be able to control those elements with designated MIDI CC with a real MIDI controller. I'm coming from GUI design for different Synthesizers and Guitar VST effects and I like to see the state in one view.

#15

I've got to agree with @johannes. I think skeuomorphic interfaces are an antipattern. The standard UI should remain scalable vector. @DragonSF, if you feel up to it, take a look at my renderer pull request. It separates the rendering details from the models in a such a way that creating an entirely separate bitmap interface would be possible and likely easier than trying to graft it onto the existing vector interface.

#16

I agree, I would be most happy, if the GUI surface can be separated from the 'circuit' design. I'll have a look at your renderer. Just give me a link (or hint) where to find it. I'm not a Java person myself (I'm more into C++ with QWT or C#), but I can program in Java. Or are talking about this: https://github.com/axoloti/axoloti/pull/371

#17

Yes, that's the one. If you already have a copy of the main repo cloned/forked, you should be able to add my fork as a remote and then pull my branches. Feel free to send me a private message if you need more help.

#18

which branch would that be? (I'm quite new to netbeans)

axbran.png395x598 20.5 KB

#19

See my private message response for more details.

I'm unfamiliar with Netbeans' Git integration. I'd suggest working with Git from the command line.