Okay, let’s start at the regular time of 19:00 UTC. I should be able to get back in time for that. Sorry to those in parts of the world that make this awkward. Maybe we can do one of these earlier one day.
So meet you at 19:00 UTC Monday 3rd May 2021. DM me if you need contact details.
[Edit] Actually, if anyone wants to join earlier, e.g. 18:00 UTC then please do. I won’t be there but if more than one of you do this then you won’t feel lonely.
Despite starting on the eve of Star Wars Day the meeting stretched well into the early hours of May the Fourth and holy mother of God, there was so much Zynthian talk, even to the point of live debugging at 02:00 CET! It all got too much for this old man who was eager for his Horlicks and bed. (Note: There is American and UK specific humour in that opening - no offence is intended.)
Some of us have been sent to Coventry
What would a swan taste like and is it worth the risk of execution?
The Zynthian code was described as someone asking for directions and being told, “If I was going there I wouldn’t start from here”
Some love was shown for Rust programming language - like C for those who can’t be bothered to learn C!
Scorn was cast on those implementing operating systems on microcontrollers - just because you can does not mean you should
We eagerly await the posting of instructions of how to step through the Zynthian code in a debugger
Using version control is a real enabler - you can make changes with abandon knowing you have the freedom to restore to a previous state
Do web browser plugins steal your data?
Sulphuric acid is the anti-ant solution
If a chemist doesn’t sell you chemicals, ask an old lady to buy them for you
Hot tips were shared on how to buy acid… enough said
How many floppy discs does an operating system distribution take?
Cascading USB hubs may stop some peripherals working
Lots of love for lots of knobs (and dials)
The PinePhone can actually make phone calls! Whatever next? An onscreen piano keyboard playing embedded setBfree? Give the man a challenge and half a Club night and he will deliver - in spades
MIDI routing within Zynthian is suboptimal
When Python meets assembly language there is trouble a(Little)Foot
On the screen, no on the phone, no on the screen, on the screen…
Roland VR-09 D-Beam - things can only get better
Does Zynthian interface let it down?
5", 7" capacative touchscreens are really good for Zynthian
setBfree on ThinkPad in a jazz club 7 years ago - then came Zynthian and it is like chalk and cheese
It used to take longer to configure synth rigs than a it took the drummer to set up
Zynthian OOBE should give you a set of working instruments
Some of us think of a snapshot as representing a whole gig
Some discussion on how using categorisation rather than the current layer / engine view
Dropping a Nord Stage will dent the ground, not the Nord
Spending thousands of often gives a good UI but not necessarily better sound
Spending thousands of may not even give you balanced outputs
Who actually needs balanced outputs?
The RD-700X has XLR outputs - this caused balanced envy
Is a 40kg keyboard portable?
API + UI redesigned would be a substantial effort but could deliver significant benefit
Should the UI be separated from a server type core responsible for reliable audio / MIDI?
Webconf is for for config - UI is for performance and sound design
Out of the box an official kit should work without reference to webconf - which we believe it does
What does each LV2 actually do? It would be good to have a description of each.
Do people tend to access the plugins they already know?
Which are the “best” plugins / engines? Can we curate this and will we trust that curation?
Software developers contribute a lot to this project - musicians, operators and artists can also contribute by informing others of what works well, e.g. which plugins are good for what purpose, what are beneficial workflows, etc. Zynthian needs YOU!
Hiding the lower quality plugins by default should be done to reduce the risk of poor user experience - you can always go looking for that stuff if you want / need it
How do we sort the good from the bad? User ratings? Curation by trusted authority?
Can we leverage benefit from external rating platforms like musical artifacts?
Action: Revisit the recent work to identify engines, presets and configurations to showcase Zynthian, implementing them as default presets.
Luckily @wyleu had left the meeting before we started to talk about tagging - we may still be there…
After discussing categorisation and how that might (not) work we considered whether tagging presets might allow a better method of finding required sounds
Zynthian could have a set of tags that are applied to each preset, e.g. plucked, bass, realistic, etc.
An encoders could be used to select and toggle tags which could filter an ungrouped list of all presets in an instrument
There could be a similar global list but there are (quite possibly insurmountable) technical challenges in allowing selection and preview from such a list
It is tempting to consider Zynthian as a monolithic monster of an instrument but it is better considered as a TARDIS - a small box containing many separate large instruments
The concept of presenting user favourite presets in a virtual bank at the top of the engine’s list of banks was proposed which would provide a collection of what you need in one place. A similar virtual bank could be implemented for curated (showcase) presets
Frank and open, critical discussion of the code included appreciation for the effort that has got us here and the path taken whilst identifying that there are significant flaws in the code that may benefit from code review including (but not limited to): consistent coding style, comments and documentation, reduced complexity, removal of redundant encapsulation, etc.
Workflows in Zynthian are not always intuitive and often distract from artistic flow
There may be benefit in splitting workflows for performance, sound design and configuration
Don’t leave a German, and Englishman and a Spaniard alone with a common interest if you need to get up for work in the morning
Day 9 of an 11 day continuous sprint was a struggle after such an intense, long and late discussion but it was much more fun than watching rubbish sitcoms alone in an apartment 255 km from home. (That is 11111111 km to you Mr Robot.)
Thanks for the HUUUGE effort of getting the summary together, and as a toast to that I’ll do my due diligence and get this done today, yesterday was such a struggle getting up that I couldn’t get myself to do it.
I’ve done some advances with this, check the repo for more, just saying I might have a tkinter gui resembling the pictures.
Nuff said, it was an amazing albeit intense discussion, and here’s hoping to more of those in better external circumstances. Long live the Zynth Club!
You are fantastic freaks, guys!! @riban, thanks a lot for this accurate report. I’m still processing it, but there is really good points there.
Sorry guys, i’m very conscious of the problems with some parts of zynthian code. I work on it almost every day . A deep refactorization would be very desirable, but the needed effort for doing so is huge and my available time for coding has shrinked, so i prefer to dedicate my coding time for fixing bugs and implementing new features.
Profiling would be very desirable too, as it’s been never done and we suspect there is some hidden bottle neck somewhere. Go for it, please !!!
In my case, my father in law take care of it
It’s improved a lot in the latest times. There are some bugs to fix, specially when reloading complex configurations from snapshots, but it will be fixed for sure.
The biggest problem i see is the lack of “per-device” routing, but this task is over my desk and i hope to implement it very soon.
Regarding the “routing interface”, i’ve thought about the proposals of a “grid” interface, but i don’t think this can fit on a small display. As @riban expressed some days ago, a contextual approach is better suited for the Zynthian-UI. Of course, there is room for improvement with the current implementation.
I hope not too much. Although it could be better for sure
Sorry, i don’t understand OOBE (Out Of the Box Experience?) In such a case, i totally agree, and i think we are getting close. The next release will came with a more curated selection. I would like to include some example snapshots and, why not, some sequencer patterns to play.
It can be used for this, for sure!
Good question, but having a balanced output is really cheap now. The DAC chip does all the work. You don’t need to add a single OpAmp.
That separation already exist. UI doesn’t touch audio or RT-MIDI. Audio processing is performed by LV2 plugins and standalone engines. MIDI processing is performed by the zyncoder library (C), that includes encoders, switches, MIDI router and filter, etc. Python code can be roughly clasified as:
configuration
engine interfacing
GUI (and others UI, via our “poors man” API: CUIAs)
routing (autoconnect)
Of course, having a good callable API with the core functionality will be a real enabler for improving the UI, for sure!, but designing and implementing such an API is challenging.
Anyway, i hope to see improved the current CUIA system and implementing an HTTP API. OSC is nice for RT messaging, but it’s not good for implementing a call/answer API.
AFAIK, It does, excepting hardware problems.
Definitely yes!! We need more feedback from musicians working with zynthian. How could we incentive them?
Oh yeah, this was not meant to be a downplay of your work, just a healthy discussion that maybe pep8 and some other standards could be followed to improve readability and the community’s ability to contribute. I could make the change to pep8 easily, I use black formatter for python in my day-job and I’ve never found any issues with it, I run it before committing in git and works wonders with regards to code formatting! (of course this would require this changes to be made in a stable branch separate from main)
We were discussing some of the UI flows there, I think some pretty interesting ideas popped up, actually we’re all in the same boat thinking that zynthian’s potential and uses have outgrown It’s initial designs and intents, and with the huge growth in features and finishing touches we though revisiting the UI flows to try and get a more intuitive user experience might bring this to more and more musicians that are maybe less technically inclined.
Yeah, we all do think that this is getting closer, curating the list of plugins, and having a few example snapshots, maybe one basic piano + pad one to pre-load as default (we were discussing that It might be desirable for zynthian to be able to make sounds as soon as it’s first powered on, like more or less what other synths do), sounds like the way to go!
I think this will come when we (as in the community) devote some time to make things like OOBE, user experience and documentation easier to understand and use by non-technical people.
Here’s hoping you can join us at some point! You got here your fellow spaniard to help you with the brit’s accents (they can get strong sometimes @wyleu )
I have to do it sooner than later, jeje!! But i’m really scared!! I spent 2 days with Mr @wyleu in BCN, and my poor brain took 2 weeks to recover from the effort of understanding the britccent
And despite everything, I love @wyleu!!
P.S. I can’t understand how these british people, with such a cryptic accent, impossible to understand for almost everybody, could be capable of inventing such a nice and pragmatic language. They probably stole their language from some innoccent indigenous tribe on some lost island.
And now it’s implemented on testing Simply update and test.
Note: You wont see the “*** Favorites ***” bank until you add some favorite by bold clicking some presets.
Blimey! Some people think we all work at lightning speed or have some kind of magic time machine that allows us to travell back and deliver software just minutes after it has been requested . I have something working in the feature branch but need to fix a few anomilies first. Watch out for a PR.
P.S. It would probably have been done by now if it wasn’t for the esoteric naming convention of the default snapshots .