what would really help picking fruit and making more jam is better documentation.
I find baerly any. floyd steinberg made a few videos, but e. g. the whole triple use of button pushes is so no obvious to me… so grasping what this machine (v5.1) can do in the first place would go a long way. most things i find out by chance…
ps: if there is more out there to learn oram or vangelis please point me in that direction.
by the way. is something like this in vangelis? like favorite parameters per chain?
Hi @sndnmd
Things can always better and it’s not intuitive at first to work with short, bold, long.
Are you aware of the Wiki and the user guides you can find there?
Things are also improving with the built-in help.
Vangelis now includes more in-line help that you can access directly from the UI. Simply bold-ALT to get the help pages. This is a work in progress and we hope to cover all main workflows and screens before Vangelis is released, Also note that many screens now have right-side tips that guides user while using the UI.
Our goal is reducing the need for external documentation to a minimum. After years of development we have realized that most users don’t read the user guide, so we are changing the approach to make documentation accessible from the UI and contextual.
Regards
yes, but it seens often very abandoned. when i bozught the kit I thought it was work in progress, but it is the same for at least a year…
i hope with vangelis and the built in help there will be more direct solutions. and therefore less frustration with new users. there is so much potential!
In a collateral but (I deem and hope) still relevant vein, I am taking inspiration from two quotations belonging to recent posts, to openly speculate about prospective directions of development of this much loved project, in a sense looking beyond the lower hanging fruits, at the upper part of the tree crown.
In my opinion, the scope and dimension of the whole Zynthian endeavour are clearly transcending the limits, of the ingenious and affordable DIY music-making solution that the concept implemented in its beginnings. Progress seldom (if never) goes backwards, thus sooner or later choices will have to be made, in order to allow this fantastic open-source solution to keep on growing and refining itself.
Regarding this, I can see solid and shareable reasons in both the core developers’ and other forum contributors’ stances. While it is perfectly understandable that a brilliant but small coding team, working mostly on a voluntary basis, tends to stick with the proven reliability and demonstrated support promise of a lightweight and affordable hw platform (Raspberry), it is also reasonable what @jtode affirms, about a single specific hardware and OS environment (actually, a carefully bordered Linux subsystem) potentially ending up in a long-term liability for the project.
I obviously realise that porting the Z program to the vastly more open (and wilder) sea of major general-purpose operating systems, like Windows/X86 and/or Intel-AMD Linux desktop, might easily prove to be an unbearable burden, of code optimization, substantial low-level changes, drivers configuration and releases maintenance, for the limited resources of a small staff.
Still, from my standpoint it is evident that the remarkable content of the Zynthian concept as a music IT station is growing, slowly but steadily, beyond the capabilities of its current container (the Raspberry SBC platform and the UX philosophy of a physical interface with a limited set of multifunctional controls). How, if and when the objective challenges, posed by the astounding evolution that Zynthian has consolidated as of late (emus, new engines, expanded sequencer, IR effects, advanced chain management, improved audio looper and other stuff) will be considered and handled by its programmers, is legitimately something that will depend on the choices, ideals and preferences of our free-will generous coders at the computer keyboard.
The very best to all 
It remains true that ARM is the most performant architecture that we can run with relatively simple passive cooling which is a core requirement of the project. If Intel or AMD had created a CPU that provides this requirement then we may have considered it. So, despite world events driving up the cost of all computer technology and some scaremongering in the press and socials, Raspberry Pi remains the optimal solution for us.
Looking past the ill-informed opinions that are being plastered over the internet, we remain confident in our choice of hardware platform. We have to consider many aspects, not just the ones that promote one view and a reliable supply chain, proven record, consistent design and quality control, open documentation, upstream support, etc are all influencing factors.
For my part, I don’t think Windows needs or deserves us, and Mac people aren’t really in it for Freedom, though I imagine it would be a bit easier there.
But my idea is strictly to choose a cheap/powerful MCU as the brain of the controls, and firm up support of x86_64 Debian as well as Raspbian, to allow people to take advantage of the greater processing power one can get there. This would not be that big a deal, I’m pretty sure, but it’s also true I’m not doing that coding. But if we could separate out CPU from the rest of the thing, it would then be up to people what’s important - if compact and portable is what you want, stick with ARM. If you’re already carrying around 150 pounds of gear and want to use the most demanding engines all at once, you can pack in a beast somewhere in the gear.
Would you help write it?
It is fair to say that some of the slightly less enthusiastic views then ours, on the features of the Raspberry architecture, come from respected and technically educated members of other specialised music IT forums.
Personally, I share a deep appreciation for the remarkable Price/Computational Power ratio, compact form factor, functional flexibility and possibility of silent operation of the Raspi SBC - a resounding engineering success and an uncommon feat of electronic design. Nevertheless, I don’t think that we should be over-protective about its objective advantages and strong points, feeling free to openly consider and discuss hardware alternatives as a stimulating topic, since we aren’t under any capacity bound to a vow of unconditional loyalty to the Raspberry foundation.
This said, and as I also stated, the clever engineering rationale behind this project - in sticking with the Raspberry platform (and the LV2 format for the time being) - undoubtedly stands, and receives my full motivated support.
Best regards
I think this may be the crux of it. RPi is not much of a contender against a workstation running a desktop OS and DAW. RPi can be okay for that but has lost its competitive advantage. But that is not what zynthian is. It is a carefully curated, embedded system. I understand and respect these opinions but they are generally not comparing like for like, or not even considering what we do here because this is niche. I spent several decades working with desktop DAWs and love what zynthian gives me, very different to those. (I rarely use a DAW now.)
Love to all in this thread. That’s my thoughts for now.
I am certainly one of the outsiders when it comes to discussing the technical or architectural details behind the reasoning in this thread, but I believe some key functional aspects can - and should - be addressed by musicians. I believe we should reflect honestly on questions like: “What do I use Zynthian for now?” and “How do I want or expect to use Zynthian in the foreseeable future?”
I know each of us has a different view and a different use case. Some of us actually create music, while others enjoy the technology and development above everything else. And that’s great!
This hits one of the fundamental questions, in my opinion. I’m also in that position. I used mostly Sonar, a few samples, and a bunch of VST plugins for many years, composing alone, until I eventually shut down my home studio. During the hiatus, Zynthian (V2) entered my world and started teasing me to resume playing - playing, not composing. A simple, silent, effective plugin host that made me consider getting together again with other musicians while bringing only a portable keyboard with plenty of sonic capability. So, not my Rhodes 73 or Korg piano, not even the lighter XP30 or SH‑201. Before Zynthian, I felt that this wasn’t possible without a noisy, expensive, and somewhat fragile laptop plus MIDI/audio add‑ons.
Fast forward to Zynthian V5. It has become a fantastic musical tool, and sometimes I even feel that we’re trying to put too much functionality and complexity into it, because we want those features, and because we have wizards capable of making them happen. Maybe that’s what brings up the feeling that we should consider more powerful architectures.
In my case, I’m fully confident that I’ll keep using Zynthian to develop my performance capabilities. But I’ve also already reflected that if I ever resume composing - even somewhat naively as before (SoundCloud) - I will definitely need to set up a new computer‑based DAW with a full screen, full everything, anchored in my home studio. Zynthian won’t be that, but it will be connected to it as a major sonic machine, alongside the hardware synths and acoustic gear.
Some fresh low hanging fruit in the Help department. I realise it’s in daily improvement at the moment 
.
and an optional suggestion:
Both of these help topics are solved thanks to @riban!
More fruit:
When no help is available, nothing happens when the help command is launched.
Would it be useful to launch the Help index if no help is available for the current page?
In that case (and all cases) it could help to rename the Index title to “Help Index” to clarify what’s happening.
Some kind of notification that help page is not available would be nice!
Agreed - and showing the help index would avoid waiting 
I had this very thought! There is a message logged but that is more for us to diagnose than for end users. I hesitated before implementing showing the index because I want to consider whether it is what users may expect and how useful it may be. (I hesitated long enough for you to raise the issue!) I am considering implementing an automatic class hierarchy drill for help, e.g. if there is no specific page for the current view, see if there is one for any of its class inheritance parents. I will play with this later… Thanks for the suggestions.
I think the expectation is to ‘show the default page’, whatever it may be 
. Today this could be the index.
This corresponds to the times when F1 in many applications gave you specific help if available, or some starting point otherwise.
There is also the user guide which may be another option instead of the index. We want the most expected behaviour.