I just searched multitimbral, just like before, it got 5 posts, 4 didn’t answer the question, 1 did, and that one had a different topic and related to an earlier version…
Yesterday, I read the manual to solve my issues with new ZS3 and I found very clearly explained how MIDI is routed to the different chains and the difference between multitimbral and active modes.
What shocked me the most was the way you could selectively choose MIDI devices to connect to the different chains. This is very powerful and fundamental and I think it deserves a little more love in the documentation 
Best
Pau
1 Like
The exlpanation is world-class, it should just tell you that you have to long press to find it, because there’s no reason to think you should
This is explained too, @lanmower .
You simply didn’t see It 
1 Like
can you please show me where this is ‘explained too?’ I just checked the documentation page again, couldn’t find it. it says:
2.2.2 Multitimbral mode
When a MIDI input is configured in multitimbral mode, only those chains matching the input’s MIDI channel will receive data from this MIDI input. No MIDI channel translation is performed. Multitimbral mode allows receiving and managing each MIDI channel individually. Each MIDI input selects the chains it drives using the MIDI channel. If you are using an external sequencer or a MIDI controller that can sequence multiple tracks (Beatstep Pro, Keystep Pro, Novation Circuit, etc.), you may want to use multitimbral mode.
and thats it, nothing about how to get to the submenu of the midi device to enable multitimbral mode.
You keep pretending like I’m dumb and I’m forced to explain over and over how 1: the documentation had nothing to say about it 2: the forums didn’t have any on topic information on it and 3: I used the exact same language you used in your own release posts to describe the exact same thing.
Rather fix the docs, like I offered to do but couldn’t cause the wiki doesn’t have a sign up
https://wiki.zynthian.org/index.php/Zynthian_UI_User’s_Guide_-_Oram#MIDI_input.2Foutput
I’d say that it is documented here but I agree that it would be netter explained before the paragraph that you indicate.
IMHO if it was explained before, concepts would be understood earlier, but as I don’t have much time to contribute I don’t dare to raise much criticisms.
Feel free to make some suggestions and they can probably be asded to the wiki.
Best
Pau
I read that too, it also says nothing about holding the button to turn on multi-timbral… to any user in their right mind, expecially when following up on the recent threads, it looks like its been removed.
There is a bunch of times someone in this thread pointed to documentation that doesn’t say what to do, I get it, there’s documentation, but they need updating like I said several times in response.
Instead of berating me, thank me for doing all this homework, and responding to everyone, and add the information to the docs 
isn’t it easier to fix the wiki than to keep telling me I cant read?
we can all agree its a core feature, knowledge on how to enable it should be abundant, and it might indicate for the long run that the ux in that spot isn’t quite obvious enough
I don’t agree that you are being beaten, just relax a little bit, we don’t search absolute truth here, just cooperation to get things better,
Recognising that the documentation is far from perfect, mainly because things have changed a lot in the last months, we have to recognise also that when you have been focused on developing everything seems obvious to you,
I think that if someone who hasn’t been involved in the development wrote the documentation, it would be more process-oriented than menu-oriented and probably easier to understand to final users.
I would gladly accept your offer to rewrite it but would feel more comfortable if you wouldn’t answer to everything trying to prove that you are right. And please don’t take me wrong, I’m just trying to make this place nicer for everyone.
1 Like
It’s not so much that you can’t read it’s what you haven’t read. Simply following the structure of the wiki would reveal much of what is required to approach the zynthian, and concepts like press length are core concepts that are introduced right at the start along with block diagrams that explain much of the basic ethos of what has been constructed. Success is often a seed for new problems, and this project is now growing on several faces. I would ask you to not accept our development process, where I very fast and reactive code process on the development branches is constantly complimented of the speed of reaction. Certainly the docs are an increasing load, and much effort is made to keep them as current as we can, but we have established the basic interface over some considerable time and we’ve refined this with specific use cases in mind. It took over three years for us to settle to how long presses behaved, it takes time, and such manipulation is VERY hard to document. It may sound complacent but these docs are certainly considerably more complete than much commercial code whatever the project managers may say. Look at a project like django if you want to see docs done right. We aspire, but if given a choice we code.
So that my apology completed. But the other reason for reading the docs is a certain culture is developed, within the docs, and within the forum,. The forum has almost certainly discussed almost every issue raised at some point and I certainly and I know other do as well, write stuff up when it settles. Everyone has been very busy. The release of v5 zynthian which was a code unification and a heavy physical interface upgrade was heavily interrupted by the release of the Pi5, which had considerable changes which we are still accommodating so as you can imagine these are primary concerns.
But it’s the cultural aspect that is probably most important, and that is where the forum pays dividends.
If I may so so you are needlessly aggressive in your responses. You believe in your way only and, I suspect you haven’t taken the time to learn to use the tools provided to access information. That is the reading that would deliver the most efficient approach and reduce the load on those of us that answer questions.
You are impatient and seem unwilling to grant any quarter on a particular point. You are also enthusiastic and productive, but these two aspects do not need to be used as stick and carrot. We don’t tend to have big rows here and our philosophy is contributory and helpful. As I have said before, try to us we rather than ‘I’. It really helps the mindset. Most of what I’ve seen achieved in technical enterprises was done because people were unconcerned by who got the praise. You do seem rather overly concerned about you own contribution over those who are actually in a position to address your concerns.
Others are not as bad as we may believe them to be and we are not as good as we flatter ourselves. And each restatement of the failings reduces the sincerity of the message.
Stick around, please, but do so as a peer. That’s how the culture works for us and that is probably the thing we are least likely to change.
3 Likes
I didn’t offer to rewrite the documentation, I offered to add a sentence that says you have to long press to see the menu, because as this thread, and other threads have made clear, is that its not apparent anywhere that you have to do that.
the point is that I have read, that was abundantly proven by me being able to identify that its not written anywhere, what was even more clear is that nobody else read the documents they threw into the chat to try and prove its written down somewhere, because none of them contained what was claimed they contained.
I was never impatient, I’m still being abundantly patient, or unwilling to grant quarter, which I’m still doing, even more so I’m giving everybody the benefit of the doubt, however the facts are plain, I stated them, and they still remain as plain as ever. I was never agressive, but you were. I did read everything available even before posting, but you didn’t, and other people didn’t either, and it was pointless to reprimand me for any of that because none of it was accurate, because I was 100% correct about it not being documented, it’s not written anywhere, and it needs to be, even after everybody had their turn at passive agressive exasperation, it still remains the fact. This thread and other threads have proven it, other users have said they couldn’t figure it out for four hours and came to the threads to find it on an off topic thread, we’ve already gone over how if you search multi-timbral in the threads, there’s five threads and one answers it but its off topic, how its not in the docs at all, this is getting beyond silly.
I was being contributory and helpful thoughout, all I’ve done so far was contribute and offer help.
What you are doing is exactly the behavior I was adressing, and I’m still chalking it up to needless misunderstanding.
This is not the image you are displaying. Please try to be relaxed and not pinpoint everything, I’ve never seen any other forum were the key people answer so promptly and solve the issues so fast as here, And they all try to be empathic and understand your use case,
If you still stick to your affirmation that a long press is the key to all the discussion then you have not understood anything, Let me state it again: we are not trying to prove who is right and who is wrong. If you want to help, please don’t lose time with these little things, focus on the goal of making zynthian better.
Best
Pau
2 Likes
@lanmower , this is explained in the in the very basic principles of operation:
https://wiki.zynthian.org/index.php/Zynthian_UI_User’s_Guide_-_Oram#Types_of_action
and later, you find specific action tables for the most relevant views, like this one:
from this section:
https://wiki.zynthian.org/index.php/Zynthian_UI_User's_Guide_-_Oram#MIDI_input.2Foutput
Regards
2 Likes
lets go over it again shall we…
5.8 Key range & transpose
5.9 MIDI input/output
Global MIDI input/output view is accessed from the admin menu. It allows to manage MIDI input/output sources and modify MIDI device global options:
- enable/disable MIDI network services
- enable/disable bluetooth MIDI devices
- toggle capture mode: ACTIVE / MULTI
- load/unload controller drivers
- rename the device
Chain’s MIDI input/output view is accessed from the chain’s options menu. It allows to select the devices from which it will receive MIDI input or to which it will send MIDI output.
In addition. you can also modify global device options:
- capture mode: ACTIVE / MULTI
- load/unload drivers
- rename the device
Initially all input devices are in ACTIVE mode. When creating a new chain, all input devices are selected by default.
tthat’s what it says, nowhere does it say ‘there’s an additional submenu for all the midi devices, you have to hold the button to see them’
Because the documentation says it’s available, but the interface doesnt’ make it available unless you magically know by asking in the forum that you have to hold the button to see it, then you don’t get to find out that the mode is actually there, you just see documentation that says it used to be there, oh and guess what half of the information on the forums makes it look like it recently changed a bunch of times and probably was removed, so please, I’ll once again ask, add a sentence to the documentation that says you have to hold the button to get to a submenu for the midi controllers, to access their device ui mappings and multi timbral mode.
It would also make sense to add it to all the other documents linked above, since none of them say that, as we\ve now exhaustively covered, the information is not available, you keep linking more documents and re-linking old ones that say nothing of the sort
OK. It’s very clear to me where the problem is. Are you reading the “touch” versión, right? It’s not complete in this section.
Have you tried to read the V5 version? What you copied is just the section overview. If you keep reading just a few lines after you would find the UI action details.
This is for the V5 but i’m pretty sure you can “translate” to touch. I recommend you always read the V5/V4 versions when you feel touch versión is not complete.
Think that the touch interface is not the primary interface for zynthian. Zynthian primary interface is rotaries+buttons.
The best
1 Like
OK! I completed a little bit this section in the touch version user’s guide:
Let’s hope this avoid further confusion about this subject.
Regards,
3 Likes
Thank you! that’s exactly what I’m talking about, some extra details to make it clearer 
So here’s what happens mentally when you get to the old page (by the way I see what you mean now)
when you drop into the page, its not apparent that the next parts are part of the flow of the previous parts, they look at first glance that they adress something else, until you look at both numbers and compare them (the one statement has a little 5.9.1 next to it, the other doesnt)
you can see on the wide screen whats happening to the reader…
The page is split into two very different columns, one for image, one for text, if you look carefully at the layout, when you read it you start reading the left and not looking at the right, when you start looking at the pictures, its easy to stop considering the text on the left… now in this case, the only clue was that the picture (which looks very similar to all the other pictures) said midi input device on it, but look at the text that you’re reading…
device options
-
knob#4
- rotate to move across options.
- short-push or bold push to check/uncheck an option.
-
UP/DOWN to move across options.
-
SEL
- short-push or bold push to check/uncheck an option.
-
BACK to back to previous view.
None of that adresses the idea that it’s going to give you a menu with multi-timbral mode, or controller drivers for that matter, you have to look at the shrunken and downrezzed photograph of a screenshot to guess it, and even then, with the latest news being those menus changing, you’d doubt its still there, you’re right that there is a world where I mau have peiced together that the arbitrary button press commands on the left and right gave me multi timbral mode, but its not searchable, in my humble opinion its not readable either unless you’re a mind reader.
You described this as being able to deduce that you can get to the multi-timbral menu there, and that I didn’t scroll down and read it, yes I did scroll down ,and I did read that section listed above that said knob 4 and some instructions, but those instructions didn’t make it clear what I’m going to get out of it e.g. device driver and multi timbral mode (both of which I spent weeks trying to fix, recover, find etc), I missed the graphics in the shrunken image on the right that was supposed to be the trail of breadcrumbs people need to deduce it (which appears to have also been the only place in the docs where that deduction is possible at all, but I argue that it was still impossible unless people point it out in the forums), that’s why people were commenting that they spent hours and hours on it, why I did too, it not really being a ‘me’ issue.
I’m very happy that the extra documentation is now there, it would suck for more users to suffer like that, most peolpe would have given up
IMHO, now that the buttons presses are documented, what is needed is more process oriented. For example:
-what happens when you plug in a MIDI device
-what are the options you have (multitimbral vs active)
-how to route MIDI input selectively to chains
It’s just an idea of a user manual and not a reference manual.
2 Likes
You are looking at the wrong chart, my friend. This is the one you have to look at:
With this text in the left side:
5.9.1 UI Actions
- knob#4
- rotate to move across devices.
- short-push to check/uncheck a device.
- bold push to open the device options.
- UP/DOWN to move across devices.
- SEL
- short-push to check/uncheck a device.
- bold push to open the device options.
- BACK to close the view and back to chain options.
It’s placed just above the one you criticized, so you step over it without putting attention …
But you are very focused in not finding the info you don’t want to find. I have no problem in recognizing that documentation is far from perfect, it can be improved in many ways, and for sure, it will. In the other hand i suspect you simply can’t recognize you didn’t look well enough, and this is a pity.
Anyway, thanks for your feedback because it helped to improve the user’s guide too.
Be water my friend!
2 Likes
I hear you, that the user is expected to look at that picture, know that it’s a submenu, know that it represents something that hasn’t changed or was removed, without any prompts that tell the user that its in fact a submenu. It makes sense from the position of the author, but not from the position of the end user, since the only prompt that tells you that it has anything to do with multi timbrality, as stated above, drastically downrezzed inside an image with a screenshot embedded in a photo, without any subtext or reason to think its another menu.
Documentation is expected to be written to be readable, if the information presented is not written anywhere in the documentation, it’s not there, even if we say users are supposed to read between the lines for things that aren’t written there, instead of the users being somehow expected to guess all this, the suggestion was to tell the user its in a submenu, a button-hold away with good reason, the reason being that it’s never stated anywhere.
