ZynewaveBeta 5 is up.
The major addition since beta 4, is that the track headers now use the same style as the new group panel. Resizing the track header height will determine which elements are shown. There are still some things to do, like updating the options in the tracks region dialog. I would appreciate your opinion on this new track header layout.
ZynewaveThe MIDI channel information is embedded in the MIDI messages that a VSTi outputs, so technically it shouldn’t be difficult to filter the MIDI notes to different slave synths, according to MIDI channel. The main problem is probably to provide a way in the UI to select the MIDI channel. When I get around to implementing this in Podium, I’ll probably use the MIDI channel settings in the device mapping properties to support MIDI channel filtering.
ZynewaveI don’t know when I’ll have this implemented. My development focus recently shifted towards improving and simplifying the existing featureset, which will occupy me for the next 2-3 months.
ZynewaveEither use the device listbox in the inspector, or arrange the waves plugins into more managable subfolders in the device list on the project start page.
Zynewave@sam c wrote:
is there an udated pdf manual or just the wiki page?
The pdf that came with the 2.22 installer is up to date with the latest additions to the wiki guide.
ZynewaveBeta4:
Another button bites the dust. The select and menu buttons are now combined into one. Clicking the button will select the track. Clicking the button when the track is selected will open the menu.
The “add effect” selector is now a simple “+” button. It can be hidden with the “show new effect buttons” option in the inspector options menu.
Clicking a selector with a send assigned will toggle the display of send controls.
Still to do:
Right-click on buttons.
Drag-reordering.
And I’m still thinking of ways to get rid of the record buttons.
Zynewave@Markus wrote:
okay, can someone make me sidechain template? Please? Thanks.
When I’m done with 2.23, I’ll make a YouTube video of how to use side-chaining. The only freeware (and stable) sidechain capable compressor I know of is Compressive by: http://www.martineastwood.com
Are there other freeware alternatives?
Zynewave@Markus wrote:
@Zynewave wrote:
@Markus wrote:
How about coding just simple compressor / duck / gate fx? It doesnt have to be good. Just that good so we can use it for sidechain.
How long it will take to code something like this? Simple duck fx? Thanks for your time.
Based on my experience with zPEQ, zReverb and zPitch, I estimate that it will take me at least a month to make a zComp. I tend to be thorough when I start on a new plugin. At present time my time is better spent on Podium, but I’m looking forward to when I get time to expand on the zPlugins suite.
No, i mean SIMPLE. Very simple. We can use third part compressors. But i’m asking very very simple ducking fx. Something what you can code like in couple days or one week. Or then you may add support to some free compressors. Or something.. Like i said, it doesnt have to be good.
I really want to change Podium to my main DAW:n. But as an electornic music producer, lack of this kinda feature is deal breaker for me (and many others)..
Anyway, thanks.
The ducking effect is achieved using a compressor and the compressor needs to support sidechain input. If you are talking about the sidechain track routing within Podium, then that is already supported. I’m sorry that it doesn’t work the way you prefer.
Zynewave@thcilnnahoj wrote:
@Zynewave wrote:
Beta3:
The selector buttons now turn into editor buttons once a plugin is assigned. That gets rid of the separate editor buttons. Good riddance, I say. When you alt+click the selector button, the effect is removed, and the effect selector menu reappears.
Is there anything assigned to right-clicking it, other than selecting the track? You could use it to bring up the replace/unassign device menu, otherwise people who don’t like keyboard shortcuts may have a hard time with it. 😛
Agreed. I’ll make right-click on the selector open the device menu, no matter if a device is already assigned or not.
Zynewave@Markus wrote:
How about coding just simple compressor / duck / gate fx? It doesnt have to be good. Just that good so we can use it for sidechain.
How long it will take to code something like this? Simple duck fx? Thanks for your time.
Based on my experience with zPEQ, zReverb and zPitch, I estimate that it will take me at least a month to make a zComp. I tend to be thorough when I start on a new plugin. At present time my time is better spent on Podium, but I’m looking forward to when I get time to expand on the zPlugins suite.
Zynewave@kyran wrote:
Here comes another suggestion to eliminate a button:
right clicking the track selection button could serve as a track mute. Right clicking a muted track could unmute it.
Left clicking still selects the track.
By track mute, do you mean effect bypass?
I can’t see how I can avoid a separate bypass button, if it should be possible to toggle bypass without key modifiers.
I’d still like the empty track to be on top of the chain, where I most of the time add new tracks.
Anyone else have a preference on where the “add effect” selector should be placed?
Zynewave@Zynewave wrote:
You know, I’m very tempted to remove the per-effect record buttons, and just rely on the source track record button
Oops, scratch that suggestion. I now remember why I made plugin automation recording optional: Some plugins will send out parameter changes in response to program changes, MIDI controller input, etc.
So you can end up with a lot of unwanted parameter tracks when you just want to record MIDI on a track.
Zynewave@kyran wrote:
Ronin made me think: is a seperate record arm button for each fx track needed. Can’t you just slave that to the group record arm button.
Is there a usecase where this useful? (I can’t see one at the moment, but I’m sure someone will tell me why this is useful) If not you could get rid of that button.
You know, I’m very tempted to remove the per-effect record buttons, and just rely on the source track record button. That would simplify things greatly. But removing them would limit some of the flexibility:
Having a record button on individual effect tracks allows the user to select whether changes made in each plugin editor should be recorded as parameter tracks. If an effect track is not record-enabled, then changes in the plugin editor are not recorded, even if the source track is record-enabled.
Maybe this is overkill, and we can just use the source track record button to indicate whether any plugin changes should be recorded. As a consequence, you cannot record plugin automation without record-enabling the source track. Thus you will need to remove the input from the track to avoid that you record over the previous audio/midi recording.
What do people think: Keep the per-effect record buttons, or remove them and live with the input unassign workaround?
Zynewave@kyran wrote:
I don’t really get what you mean with those config options. A bit like the editor profiles?
Yes, although much more simplistic. But I have now abandoned that idea.
What I’m missing now, after playing a bit with the new layout is a quick way to reorder the fx tracks. I’d really like to be able to do this with drag and drop. I think that this is quite essential.
I plan to implement drag-reordering using the effect selector buttons.
The other panels feel quite redundant now, all their functionality is (much more intuitive) taken over by the group panel. I think you can remove those and gain quite some real estate in the inspector.
I plan to add a “List” (in lack of a better word) option button at the top so that you can toggle the panels on/off. The object lists are still useful when you want to browse through presets, etc.
The top panel will eventually have these option buttons: [Color Picker], “Rack”, “Editor”, “Meter”, “List”.
The “Editor” button will enable/disable display of embedded plugin editors. The “Meter” button will show/hide the large meter.
Now here comes the wishfull thinking request: embedded editors for all vst’s. Each vst should have an embedded editor with 8 knobs (think racks in live). Like you have “add parameter track” option in the menu now, you could also have “link parameter to knob”, which will map that vst parameter to the knob, so you have it available for instant tweaking. You could also save this mapping in the plugin template so it’s restored each time you use it.
The zPlugins have their own embedded editor. All other plugins will be shown with the generic plugin editor. The generic editor shows by default all available parameters in a scrollable list. I’m thinking I could add an “include in inspector rack” option in the parameter properties. If this option is not enabled on any parameter, then all parameters are shown in the embedded editor. If there are parameters that has this option enabled, then only those will be shown in the editor.
Zynewave@thcilnnahoj wrote:
@Zynewave wrote:
Besides the redesign of the group panel, the following is also implemented in beta1:
• Improved stability of plugin multiprocessing.
This involved a change to the way that the plugin processing is distributed to the available cores, so I would appreciate if you could try the beta1 and let me know if you notice any change for the worse in plugin CPU usage. Especially if you’re on XP. My XP machine is not running a multi-core CPU.
Okay, this may not be a very scientific test, but judging from the graphs in Windows task manager, CPU usage is more evenly distributed between my two cores in a CPU-munching project compared to 222. It seems I’m also getting a lot less red flashing in the CPU indicator at low latencies (Vista 32-bit). Could this be due to this change, or must there be something else at work? 😳
That sounds right. In previous Podium versions, the audio thread would activate a bunch of worker threads that would start to process the pool of plugins. The audio thread would then go to sleep and wait for the worker threads to complete. This is now changed so that the audio thread does not go to sleep but instead helps out with the plugin processing. That makes the CPU utilization smoother at low latencies, since the lag that can occur in the Windows thread-switching is reduced.