Zynewave@ninjawarrior wrote:
@Zynewave wrote:
I don’t know why some plugins support mouse wheel only in some hosts. As far as I have tested, I am not doing anything in Podium that should prevent a plugin editor from supporting mouse wheel.
Maybe it is about this shortcut stealing.. Same thing than plugins steal space button. Podium lost keyboard / mouse tracking / support or something. Which is btw so annoying. I send you email about this, but i didn’t get any respond, so i guess you have no intention to fix this.. 👿
I read your email, and I still have it in my inbox. I do intend to do something about the plugin key stealing at some point. Please be patient. There are a lot of things on my todo list.
Zynewave@Trancit wrote:
Normally (if I look at the most hosts), mousewheel alone changes bigger values, with shift or ctrl as modifiers smaller amounts…only one host makes it other way round and I have to say, this works much better:
Imho, if you want to make bigger changes to a fader or knob, it´s far easier to grab it by left clicking and move it…
So, why do we want the mousewheel: especially for smaller changes/fine tuning or slower changes it´s far easier to use the wheel and that´s the reason, why I personally find it much easier to have small increments without modifiers and bigger ones with…
On a volume fader, the mousewheel shouldn´t change the value more than 0.5db, perhaps only 0.33db…take a look at MU.LAB from Mu.Tools…mousewheel on the volume fader changes value in 0.25 increments…works pretty good!
Try the latest 2.37 beta 4. So far I have made mousewheel adjust in 1 dB steps. Shift+wheel adjusts in 0.1 dB steps.
I can see your point about the reversal of the coarse/fine with the shift key, but I think there are arguments to keeping it the way it is. Using Shift for fine adjust is identical to the use of Shift for fine adjust when click+dragging a fader. Also, with the recent support for zooming mixer strips to 20%, it is convenient to use the mouse wheel for coarse adjust of pan and send, since the strip can be zoomed so small that you can’t reliably drag the knob.
Zynewave@Trancit wrote:
I don´t have any knowledge of programming, but could it be, that plugins, that don´t have extra mousewheel support themselves, could benefit from this “hoovering over the dial to set mousewheel focus on that”????
The sentence you quoted, is that an option you have seen in another host?
Btw. I see you are using “hoover” in your posts. The correct spelling is “hover”. Hoover refers to a vacuum cleaner.
And a second question:
Is it a big effort to implement midi controller mapping to Podium elements for hardware controller support???
I don´t think it´s necessary to support special controller directly in first place, but to map a midi CC to a fader or button is quite essential these days with so many brilliant controllers available 8)
I’d estimate it would take me 1-2 weeks to implement. The problem is that there are many items on my todo list with a similar priority. I have to work on one feature at the time.
ZynewavePodium does not yet support general MIDI controllers. Only Mackie Control compatible devices are supported for controlling the Podium mixer.
You can control a plugin with a MIDI controller, if the plugin supports MIDI learn natively.
ZynewaveBeta 4:
Mouse wheel can be used to adjust gain, pan, send and parameter faders in the mixer. Holding the Shift key will fine adjust. Gain faders are adjusted in 1 dB steps, and 0.1 dB fine steps.
Ctrl+clicking a parameter fader in the mixer will set it to the default value.
Zynewave@Pigini wrote:
@Zynewave wrote:
The problem is that it is not implemented. Only the timing clock is transmitted, which can be used to sync e.g. external delay units to the Podium tempo. Start/stop messages are not transmitted. With my current todo list, it’s going to be a long time before I have time to add support for this.
Are Start/stop messages difficult to implement? It seems such a basic thing. I would have thought it was just overlooked at the time, but not that it was hard to do.
Not particularly difficult. It’s just that there are so many non-difficult things on my todo list. Lately it feels like that for every feature I implement, two new requests are added to the list. I’ll have to put some of the requests that are only relevant to a small percentage of Podium users on a todo-in-the-future list.
Zynewave@Trancit wrote:
But you should definetely consider mousewheel support as well for plugin windows…the mousewheel controls the window which has focus on…
I don’t know why some plugins support mouse wheel only in some hosts. As far as I have tested, I am not doing anything in Podium that should prevent a plugin editor from supporting mouse wheel.
ZynewaveI’m currently implementing support for controlling sliders/faders with mousewheel in the mixer. I’m only planning to support it in the mixer, as I think mousewheel slider adjustments in the rack and track lane headers would conflict with the normal use of mousewheel for scrolling up/down in the track list.
The latest news I heard about Poise, was that the developer had found a new way to support mousewheel.
Zynewave@swindus wrote:
There is a problem with sending MIDI clock/start/stop. Podium sends MIDI messages to the MIDI clock enabled output but the external device does not start playback (in my case a MIDI hardware sequencer). With Reaper or Studio One the external device slaves perfect to the sequencer playback.
The problem is that it is not implemented. Only the timing clock is transmitted, which can be used to sync e.g. external delay units to the Podium tempo. Start/stop messages are not transmitted. With my current todo list, it’s going to be a long time before I have time to add support for this.
ZynewaveThat’s the way it used to work. You had to manually create the sound event on the bounce track, either by doing an offline bounce first, or by drawing in the sound event. This behaviour was changed in Podium 2.35. It is no longer necessary to manually create the realtime bounce sound event. Will be available in the next Podium Free 2.35 release.
Zynewave@thcilnnahoj wrote:
The parameter automation chapter got revamped! I’m sure I’ve missed things, but it should be ready for review anyway. I’ve changed my screenshot naming scheme to include the version number instead of the date.
Many thanks. I’ve now revised the text, and added extra info on the mixer faders in a new section. My revision is now ready for review 🙂
ZynewaveHi,
The fluctuation you hear is caused by the algorithm that tries to find the best overlaps in the repeated waveform splices. It will depend on the source waveform, and it is not something that can be synced to host tempo.
Frits
ZynewaveThanks, and welcome to the VIP club 🙂
Zynewave@Malcolm Jacobson wrote:
The only thing I still find confusing is the behaviour after bounce. If I enable Realtime Bounce (my preferred bounce method when jamming with VSTi’s) then enter Record, the audio file is displayed while recording – but disappears when I press Stop. I think this is very confusing behaviour, and the first couple of times I tried it I thought I had done something wrong. It took me a few goes before I found out I had to enable the playback of bounced audio after recording in order to view/listen to the bounced track.
Could this behaviour be changed (even if it’s something that can be enabled by preference) so that the audio is displayed and plays back automatically after creating a bounced recording?
I’m not sure what the best solution is to this. Suppose you have disabled the “deactivate record mode when playback is stopped” option: When you stop playback (with record mode still enabled), should the bounce record mode stay activated in case you want to continue recording, or should it switch to bounce playback?
Or should it be the deactivation of the transport toolbar record button that switches to bounce playback? And what if you switched record mode on/off without recording anything?
Suggestions anyone?
ZynewaveCool. Do you plan to make more production videos?