I’ve added a ‘show audio meters’ option to the tracks region properties dialog.
@Conquistador wrote:
I think this makes sense, is this correct?
You are correct in your interpretation of send/return. But as said in my previous posts, this is all changed now so that input/output is used instead. Bus mappings still use send/return labels though.
I have never seen in any audio software a place or a term to “send the output of the software to the internal input of the PCI bus which sends the signal to the physical output” !
What you are writing is something like this.
Even if it is true in the computer, and logical if we follow the path of the bits, it is not relevant for the user.
For him, and for all audio/video softwares UI, the output of the software IS equivalent to the output of the physical interface.
I don’t quite follow the association with the PCI bus. In the context of working with devices in the arrangement, my perception of external hardware devices is exactly the same as plugins. If you use “input” as description when you send audio to an fx plugin, the same “input” label should apply when you send audio to an external fx unit. The confusing aspect is in the configuration of the mappings for external devices, where you have to select the “output” interfaces in the PC that you use to connect to the “input” connectors on the external device. It is this contradiction in terms that I tried to avoid by using the words send/return.
I have now changed the device mapping properties dialog. The labels for “MIDI input configuration”, “MIDI output configuration”, “Source channels/speakers” and “Target channels/speakers” now change according to the type of mapping. E.g. for a plugin mapping the audio source and target labels now instead read “Mixer input (plugin output)” and “Mixer output (plugin input)”.
There is nothing mysterious here. The VST spec provides a function called getEffectName() which the host can use to query the plugin for the effect name. This name is not related to the filename, but most plugins will return the same effect name as the plugin filename. It seems the hosts you tested ignores the effect name returned by the plugin, and instead uses the filenames.
In Podium I name the imported mappings after the effect name rather than the filename, because this in most cases provides a more accurate name. E.g. the “LPLL2.dll” plugin is imported as “LALLAPALLOOZA lite v2” because that is the effect name returned by the plugin.
The hyphen in the “GEQ-7” is there because that is the effect name returned by the plugin. So the GEQ-7 plugin is an example of a plugin that returns an effect name that is different from the filename. Unfortunately in this case the filename provides more information than the effect name. My advise is that you rename the imported GEQ-7 mappings and add the S and M manually.
Somehow Podium is receiving only ‘part’ of the information Torben has made available to be read by a host.
I don’t think that is the case. My guess is that the other hosts simply show the filename (minus the .dll extension) and ignores the effect name provided by the plugin. If you rename the filename of one of your plugins, does the plugin appear in your other hosts with the renamed filename?
And how about mixer bus mappings: Would you want a mixer send mapping to be labeled input or output? Or should it still use the current send/return labels?
What I liked about the send/return labels was that they could fit all types of device mappings.
We’ve had this discussion quite a few times now. It’s a matter of point of view.
But I wonder why the inputs are named Send, and the ouputs Return ???
Using the “send” and “return” description was an attempt to make it clear that it refers to how the Podium mixer sees the devices. I’ve now changed it so that it uses “input” and “output” instead, from the viewpoint of the device. This results in the naming you want for plugins. But it also means that mappings for external hardware devices will show “MIDI input” followed by the name of the connected MIDI output interface, and “MIDI output” followed by the name of the connected MIDI input interface. When someone someday posts that they find this confusing, I’ll just link to this topic then 😉
And the exception to it all is of course the MIDI input, audio input and audio output mappings, which are not “devices” as such, and thus are seen from the viewpoint of the mixer. For these I inverse the input/output description. Otherwise a MIDI input mapping would have the description “MIDI output”.
Downloaded, tested and confirmed. Could it be that the hosts you say display the names correctly are showing the plugin filenames? When Podium requests the name from the plugin, the same “GEQ-7” string is returned from all three variants. I have emailed Torben with a few questions about this.
Right click the preset panel header.
It must be Tracktion that appends the M and S to the plugin name.
Is it time now ?
Not quite there yet. Currently my focus is to complete the transition from the project wizard to the project start page. After that I’ll get rid of the project wizard to avoid confusion.
“Sound (Master)” profiles will be used when you open a sound object from the browser. “Sound (Slave)” profiles are used when opening a sound from the arrangement editor. Slave profiles don’t have the transport toolbar because they are locked to the arrangement.
and if I change its profile to Master, then when I double click on a sound event it opens the List window instead ???
That’s probably because you then no longer have a “sound (slave)” profile and Podium then searches for the next best thing, which is editors configured as “All types”, i.e. the event list editor.
An option to detach a sound editor from the arrangement is on the plan.
Could it be also a global option for all the tracks ?
The option is enabled by default when you create tracks by dragging objects and when you double-click parameter objects to create automation tracks.
Is there a way to load two instances of the same vsti?
Yes. If the plugin is imported as an insert mapping, you just drag the mapping to new tracks to create new instances. If the plugin is imported as a global plugin (mappings have (#1) in their name) then you need to create additional sets of mappings for each instance you want to use. Currently the easiest way to do this is to import the plugin again, which will create mappings with (#2) etc. in their name.
For the next release I’m going to add a “Duplicate New Instance” context menu to the device list on the start page. This will make it easier to create additional instances of global plugins, mixer busses etc.
