Did you include peak program meters? It would be good to see a little video of it working .
I currently only tried the faders and some buttons. I am currently testing some of the scripting features of TouchOSC (Lua). The heartbeat runs fine (with optical representation in the UI).
Regards, Holger
Iām currently running this under testing.
Iāve loaded a FluidSynth layer, with a soundfont and preset. How do I go back to change the preset without having to create a new layer - it used to be āBackāā¦
Gonzo
Use SELECT encoder to highlight the channel. Short press SELECT to go to control screen. Short press SNAPSHOT to go to preset screen. Press LAYER to go to bank screen.
I donāt like this navigation but some other work for in the way of resolving this. I think we can revisit this now that z2rf is merged.
It seems a little bit tricky to show the parameters. My current problem is, that the parameters are -200.0 (for no signal) and between 0.0 and ~30.0 for a signal - what seems to be the signal level in dB.
The fader object wants to show values between 0.0 an 1.0. So there are two ways to solve this:
- Add a script part to the Touch-OSC fader object which maps to positive values between 0.0 and 1.0
- Change the ZynMixer to output values between 0.0 and 1.0
The ācleanā way will be solution 1, so I will try to manipulate the āxā value and map it to 0.0ā¦1.0. But I think -200.0 db as minimum input level is much to low. I will map it to -100.0 db.
Regards, Holger
Hi Brian @riban,
Iāve gotten a little further now: I can display the received dpm[0-15][ab], but TouchOSC has (IMHO) currently quite a few bugs.
One problem is that I built a fader unit per channel and then copied it. For some reason there seems to be an internal ID in the background that couples some faders together. I can not decouple this in the interface.
Another problem exists inside Zynthian: You can display the available OSC hosts in TouchOSC via zeroconf. Zynthian offers both its IPv6 and its IPv4 address, but the OSC messages seem apparently only sent/received on IPv4. Since TouchOSC seems to randomly choose one of the address types, you have to manually enter the IPv4 address of the Zynthian. Can you extend ZynMIxer-OSC with IPv6?
Another Zynthian problem (but I havenāt investigated it further right now): When I have my test setup triggered by a KeyStepPro arpegiattor over a few hours, the mixer on the Zynthian screen seems to stop displaying its levels. With OSC, however, I still get values.
Until I get the TouchOSC bugs solved, I wonāt be sending any videos yet, because it just looks broken at the moment. I will send an error report to Hexler.
Regards, Holger
Hi @riban Brian,
now I started over again and created a new TouchOSC interface (due to program problems with the last try). Currently only MIDI channel one and the master:
There seems to be a problem with the dpm values. They are displayed linear but the values should be displayed (IMHO) logarithmic(currently donāt know how to do this with TouchOSC)?
It seems that the balance does not work. Changing values does nothing. Also the mono button seems not to work.
Does the master channel has a balance and mono button?
Regards, Holger
Hi @C0d3man
The OSC presentation of DPM does have a log scale but it is only the peak hold values that are sent, not the nice dynamics of the meters implemented in the UI. I probably did this to thin traffic and avoid overloading the processing.
Balance and mono should work. They were tested working previously.
Main mix bus channel does have balance and mono controlled in the same way as any other channel. It also has solo button which disables all channel solo.
[Edit] I just tested balance, mono and main mix bus control via OSC and all worked as expected. I used this little python test:
import liblo
liblo.send(('localhost',1370), liblo.Message('/mixer/mute16', 1))
The mixer is cool, and makes it much easier to balance levels when several instruments are open.
I like the way its easy to āfocusā an instrument when in stage mode. However I am having a problemā¦
When I load Aeolus there are four layers created, one for each of three upper manuals, and one for the pedals. However, only the last layer (#4) appears in the mixer, so when adjusting the volume it is only possible to hear the pedals. The other layers can be selected by pressing:
āselectā (opens the control page), and then ālayerā (to cycle to the next layer). But when re-selecting Aeolus in the mixer it resets the focus to the last layer.
Is this the intended behaviour? I guess it might not be so much of a problem in multi-timbral mode. I think it would be useful to either show all 4 layers in the mixer, or somehow remember which layer to focus when selecting the instrument.
That is a known issue. I think there is similar behaviour for setBfree. I intend to fix it when we have changed the core to support the mixer workflow better.
OK, thanks. Yes setBfree has the same issue, but it is possible to instantiate setBFree with just one MIDI channel, which for me is usually enough. On the other hand Aeolus always has 4 channels, so the problem canāt be avoided.
Hi,
I tried again with no success. There are strange errors inside TouchOSC. And I think I found a problem with the zynmixer master fader. What I have done:
- Update Zynthian
- Load an instrument (I used the first one with the first sound on MIDI#1)
- Change the faders on the touch screen.
This works sometimes for both (fader0 and fader16 (=master)) but sometimes the master fader16 is locked in position 0. Changing the position of fader16 is only recognized for a short moment, than it falls back to 0 again.
Sometimes this error only happens after a reboot (with using the last setup automaticly enabled).
The next problems seem to be inside TouchOSC. To map the db-values to a value from 0.0->1.0 I used a (Lua-)callback then receiving an OSC message. But only on test setups (clean start with only one fader) this works. Creating a bigger setup with all the other functions or only copying the faders gets strange behaviour of TouchOSC.
For decided to wait for updates for TouchOSC until I am trying again. Itās very frustrating if you canāt locate the problem exactly.
Regards, Holger
The mixer idea is a very excited feature !
Do we know when it will be available for the stable branch ?
Thanks again for the incredible work !
It will be some months before stable is updated. The changes occurring on development and testing branches are substantial and need a lot of work and testing. We are not close to finishing that. Mixer in Testing is really still a period of concept and does not use the design that will be in the next stable release.
Ok , thanks Riban !
Was there a workaround method for finding the midi channels? I canāt find the ones I have added anywhere?
Only way at the moment is to ensure there is an audio layer, enter the control screen of the audio layer then use layer button to step through layers.
We have to refact the Audio Mixer so it becomes the āChain Managerā
Testing was updated this week to implement the high-level āchain managerā workflow. (The low level implementation is still being worked on. The current implementation continues to use layers.) A significant change is that all chains (layers) are now shown including MIDI only. The latter is displayed without any audio controls (fader, solo, mute, DPM) but still allows selection and hence access to the control screen. The implementation is now quite feature rich and stable. Thanks to @jofemodo for fixing some issue I reported. This change fixes presentation of the setBfree and Aeolus organs which present as multiple layers. Note that audio is presented on the highest / right-most mixer strip for each of these engines and removing any of their layers will remove the whole instrument. This may seem a touch counter-intuitive but it makes (some) logical sense.
Horizontal scrolling of the mixer can be achieved by moving the selection highlight with the SELECT knob, touch/click and drag or by moving the mouse cursor to the bottom of the screen and using the mouse wheel. Mouse wheel can also adjust fader level and pan/balance by hovering over the relevant control. (This obviously only works if the pointer cursor is enabled.)
Now for a question for the class⦠Now that we have audio level and pan / balance control, could / should we lose these controls from the engine control screens, e.g. within Sfizz we could lose āvolumeā and āpanā controls. Whether we keep these controls or not, should we lose their default MIDI mapping (CC7 for volume, CC10 for pan)? Should we map CC7 to mixer strip level and CC10 to mixer strip pan/balance? Should we map CC numbers to mute and solo? How should we control the main mixbus strip? (We could limit ourselves to 15 channel strips and use MIDI channel 16 for main mixbus but it seems wrong to me.)
I havenāt figured out a way to enable MIDI learn in the mixer view hence the questions about whether we could/should have static mapping or at least, default mapping. Many of you have asked about controlling the mixer via MIDI. How about having this default MIDI mapping and controlling it via webconf? It isnāt as intuitive as MIDI-Learn but maybe for this core module it is acceptable?
Please contribute to this discussion to help shape this core functionality. The mixer view is now the home page for the Zynthian and presents a fundamental workflow. I encourage you to try out the testing branch but do so on a spare sd card so you can get back to stable branch. (The two are not currently compatible.) There remains a plan to add an effects chain to the main mixbus but that is not yet implemented. Bear that in mind with any suggestions, e.g. toggle mono is not currently possible on main mixbus but would be available once there is an effects chain context menu available.
[Edit] A sneaky little addition tonight - you can now configure the quantity of mixer strips shown. The configuration is in the advance settings of webconf User Interface. Range 1-16 or Automatic uses the screen resolution to chose a suitable quantity. Update and enjoy!
A default MIDI config could be interesting: CC#7 for volume, CC#8 for balance, etc. but a MIDI learning mechanism should be implemented too.
Iām not sure that removing the āvolumeā and ābalanceā from āsome enginesā is a good idea, but some engines have these parameters controlled by CC7 and CC8 or CC10, what makes challenging to have this default MIDI configuration for the mixer.
The engines that currently use CC7 for volume are:
- fluidsynth
- sfizz
- linuxsampler
- setbfree
The engines that currently use CC10 for balance are:
- fluidsynth
- sfizz
- linuxsampler
Letās think about it ⦠,-)
Enjoy!