Zynewave's Forum Page

@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?

@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.

@Markus wrote:

Now we have little mixer here. How about that orginal? Please remove those fx in there. Main purpose was get rid of that “scrolling up and down effect”.

The mixer will get a major revision later on. The updates to the track management in the latest Podium releases have left the mixer lacking in some areas. I want to complete the track management features before I start on the mixer redesign.

I also think that you should add there empty slots. Like 8 pieces. Example here

I don’t think that is necessary when we have the new “add effect” selector in the chain. You can use that to easily add any number of effects. No need to have a predefined number of empty slots.

Beta2 is up. Another revision of the UI, and a few bug fixes.

@Zynewave wrote:

I considered a solution where an empty “” box would always be placed at the bottom of the chain. Select an effect here, and a new empty effect track is automatically inserted at the bottom. But that means that there will always be two unused tracks in the chain (one in the master chain), and I think that takes up too much space.

I changed my mind on this, and I have now added an “add effect” combobox at the bottom of the effect chain. Let me know if this is convenient or a nuisance.

I’ve incorporated some of the suggestions made in this topic, so hopefully the revised UI is now less caotical 😯

Tomorrow I’ll go through the posts in this topic and reply to questions.

It looks like a major improvement, but I can’t really see a fast way of adding a new fx to the chain (except if there would be some drag and drop functionality with the browser).

If you click the right-most menu button, you get a “new effect track” command that will insert an empty slot. You can then select the effect from the effect selector combobox.

I considered a solution where an empty “” box would always be placed at the bottom of the chain. Select an effect here, and a new empty effect track is automatically inserted at the bottom. But that means that there will always be two unused tracks in the chain (one in the master chain), and I think that takes up too much space.

Personally I’d like the inspector to be a mini mixer strip (like in ext2 and logic). A good meter view would turn your current design into this.

A large meter in the inspector will come in a later release.

About the redesign of the track header: it is defenitely too cluttered at the moment, but I don’t think you should put this design on it. Currently the inspector, the mixer and the track header all show the same information. This is a lot of redundancy. The track header should be more minimal (I hardly have my track sizes so big that you can you can actually see any of the stuff it’s trying to show now).

The track header should just contain a custom name, the smrb buttons, and maybe pan and gain controls. If you want to know more, select it and have look in the inspector (that’s what the inspector is for right?)

I don’t intend to put the entire group panel on the track header. I plan to remove the display of the effect chain on the header, and just have the instrument and input comboboxes along with editor and bypass buttons. Optionally have the send, gain and pan sliders there as well.

I’ll also try to make the rectangular BSMR flat buttons into normal buttons, for consistency.

A final remark: you’re stepping away from the integrated gui of the z plugins with the inspector then? Your current design doesn’t really leave room for these.

In a later release I’ll remove the embedded plugin editor from the track panel, and instead insert it into the group panel, just below the combobox where the effect is selected. That will allow a zPEQ editor to be open when the source track is selected, and it also allows multiple embedded editors to be open at the same time. For this purpose, there will be a new button next to the current ‘E’ button, which will open/close the embedded editor.

Thanks for the input.