@swindus wrote:
I did a quick test and beta 4 is still crashing when I delete the last track in the project I sent you if the inspector is hidden.
Ouch. Please try the new beta5. I had only tested that it didn’t crash when you hid the inspector after entering the arrangement. Now it should work also when the inspector is hidden before opening the arrangement.
Thanks! Looks good now, no crash so far.
Found another bug:
– Insert a wav file on a track.
– Open the wav file in the sound editor and copy a segment from the wav file to the clipboard.
– Create a new track.
– Create a new event on the track and open it in the sound editor.
– Place the edit cursor outside the range of the new event!
– Paste the clipboard content to the event (Ctrl+V or menu command).
– Crash.
Happens only when the edit cursor is not in the range of the event where the audio content is pasted in.
@swindus wrote:
Found another bug:
– Insert a wav file on a track.
– Open the wav file in the sound editor and copy a segment from the wav file to the clipboard.
– Create a new track.
– Create a new event on the track and open it in the sound editor.
– Place the edit cursor outside the range of the new event!
– Paste the clipboard content to the event (Ctrl+V or menu command).
– Crash.Happens only when the edit cursor is not in the range of the event where the audio content is pasted in.
I’ve tried this various ways now, but I cannot get a crash. Can you send a project file with the tracks and events prepared, or post some more details?
Project file sent.
@swindus wrote:
Found another bug:
– Insert a wav file on a track.
– Open the wav file in the sound editor and copy a segment from the wav file to the clipboard.
– Create a new track.
– Create a new event on the track and open it in the sound editor.
– Place the edit cursor outside the range of the new event!
– Paste the clipboard content to the event (Ctrl+V or menu command).
– Crash.Happens only when the edit cursor is not in the range of the event where the audio content is pasted in.
Thanks for the project file. This bug is fixed in the new beta6.
@acousmod wrote:
There is no change for the plugins that are not recognized as multichannel (the list in my previous post).
Is this because you are yet working on it or because it is not possible ?
I tried the Tobybear DMO bag from your list, and made some further changes to the import. I think Podium now will import all multichannel plugins correctly as inserts. Let me know if there still are plugins that are not recognized as multichannel.
The beta6 has a new “enable plugin processing during preset recall” option in the preferences dialog. This is disabled by default, and when disabled Podium will work as in previous versions. Enabling this option may reduce the CPU spikes that can occur when activating monitoring and when changing plugin programs/presets. Podium has so far always skipped processing while preset recall was in progress, due to the fact that there were some older plugins that would crash otherwise. This was years ago, and with a bit of luck there are not many plugins left that have problems with simultaneous processing/preset recall. Please try enabling the new option and let me know if you notice any change at all in CPU spikes, or if you find plugins that behave badly with the new option enabled.
I think Podium now will import all multichannel plugins correctly as inserts. Let me know if there still are plugins that are not recognized as multichannel.
All plugins are now well recognized, including ambisonic and Pluggo made, except the 8 channel versions from Acon : Studio Necessities and Studio Clean.
http://www.acondigital.com/us_StudioNecessities.html
I think that they are linked to an ini file or something like that.
Please try enabling the new option and let me know if you notice any change at all in CPU spikes, or if you find plugins that behave badly with the new option enabled.
I will try…
@acousmod wrote:
All plugins are now well recognized, including ambisonic and Pluggo made, except the 8 channel versions from Acon : Studio Necessities and Studio Clean.
http://www.acondigital.com/us_StudioNecessities.html
I think that they are linked to an ini file or something like that.
I downloaded the Studio Necessities demo, and modified the ini file to support the maximum 8 channels. Through debugging it appears that the plugins support the setSpeakerArrangement function, but it only reports success with the mono in/out arrangement. It fails on all other channel combinations I’ve tried. I don’t think I want to fix anything in Podium to compensate for this. If a plugin reports success on one or more setups, then Podium must assume that any setup that it reports failure on is unsupported by the plugin.
Yes, it is not your fault.
I will ask the the developper if he can correct it.
Thank you for all Frits !
It is now really a pleasure to import plugins 😛
Perhaps a small request if I dare…
Could you eventually add also a multichannel mapping for instruments who have multiple outputs together with the stereo one ?
Could you eventually add also a multichannel mapping for instruments who have multiple outputs together with the stereo one ?
I’m not too happy with that. It would mean that importing a stereo-only multiple output instrument will create a useless surround mapping, which may confuse users that only work in stereo.
Absynth4 and Cronox3 are the only surround capable instruments I know of. Can you list other surround instruments?
I’m not too happy with that. It would mean that importing a stereo-only multiple output instrument will create a useless surround mapping, which may confuse users that only work in stereo.
Yes, I understand.
Absynth4 and Cronox3 are the only surround capable instruments I know of. Can you list other surround instruments?
I agree that they are quite few and that it will not help a lot of people…
Reaktor (8), Kontakt (16), CrusherX (10), Independence (9), MachFive (6 ?), GigaStudio (?), Halion (combination of stereo and 5.1), and of course my little toys 😉
Forget it !
@Zynewave wrote:
The beta6 has a new “enable plugin processing during preset recall” option in the preferences dialog. This is disabled by default, and when disabled Podium will work as in previous versions. Enabling this option may reduce the CPU spikes that can occur when activating monitoring and when changing plugin programs/presets. Podium has so far always skipped processing while preset recall was in progress, due to the fact that there were some older plugins that would crash otherwise. This was years ago, and with a bit of luck there are not many plugins left that have problems with simultaneous processing/preset recall. Please try enabling the new option and let me know if you notice any change at all in CPU spikes, or if you find plugins that behave badly with the new option enabled.
My own tests do not show much improvement with this new option, so I’m going to remove it again and revert to the behaviour of previous Podium releases. No need to fix anything that is not broken, especially when it comes to VST support where the slightest change in host behaviour is almost certain to cause problems with some plugins. There were no feedback on the beta6, so I take it that noone saw an improvement with this option.
There were no feedback on the beta6, so I take it that noone saw an improvement with this option.
I have not made extensive tests, but I have seen no difference too.
Other subject, concerning the final 1.97, do you confirm that the ZPitch plugin will be multichannel like the EQ ? (it will be a great help for my current work)
Other subject, concerning the final 1.97, do you confirm that the ZPitch plugin will be multichannel like the EQ ?
Yes, already done. I expect to release 1.97 this weekend.
On a sidenote, since this topic is about VST: I have briefly studied the VST3 SDK which was released by Steinberg yesterday. The VST3 spec is a completely new format that is not backward compatible with previous VST versions. So supporting VST3 is not just a matter of updating the VST support in Podium.
Of all the new features that Steinberg promotes in VST3, there is only one major feature that cannot be done already with VST 2.4 in Podium, and that’s the sample-accurate parameter automation. VST parameter automation in VST2.4 is batch processed at the start of each sample-block with the block-size defined by the ASIO driver. If you are using low-latency ASIO settings (i.e. small buffer sizes) then this is less critical, as the parameters will be updated with only a few milliseconds delay.
Other major VST3 features (silence-optimization, dynamic IO, side-chaining) are already doable with VST2.4, and is supported by Podium.
I expect that it is going to be a long time before (or even if) VST3 overtakes VST2 as the dominant format. So I won’t be looking at adding VST3 support to Podium in the near future.
@Zynewave wrote:
There were no feedback on the beta6, so I take it that noone saw an improvement with this option.
…”no feedback” may also mean that it might be better going back to doing internal testing and then releasing an update for feedback like before.
There are likely many different reasons why so few have participated in Beta’s here but unless you just cannot spare the time anymore to do your own tests internally like you used to do some time ago (which were more than enough for a really rock solid app) then I would suggest perhaps going back to your own internal tests might be better.
Also…from a marketing standpoint more frequent releases (4 weeks at most) would serve Podium better as recent release schedules are around 6 – 8 weeks which more than doubles the normal time between KVR announcements (2 -4 week schedules, earlier last year) which of course is crucially free Podium advertising to KVR’s 150,000 strong membership.
Just trying to help here.
I expect that it is going to be a long time before (or even if) VST3 overtakes VST2 as the dominant format. So I won’t be looking at adding VST3 support to Podium in the near future
I agree. For now I would side step it. Totally.
Sonalksis Head dev. had this to say about VST3…
“VST3 support is going to require a SPECTACULAR amount of work. Porting to VST3 is going to take months of work and test.
Do you think users would prefer we spent those months porting to VST3 or making new plugins?”
The full and interesting VST3 thread (if you have not seen it already) can be found here.