thcilnnahoj's Forum Page

I found some time to give reformatting (just hope I didn’t mess it up) the preferences chapter a try. Lots of stuff left that I couldn’t explain very well, or not at all. 🙁

If it’s okay, I’d like to have a go at the Loop-Recording and Composite Tracks section, which looks like it needs screenshots as well.

@pquenin wrote:

– I have seen nothing to insert bars somewhere in the arrangement,

You can do that with the segment tool (second tool from the left). Click and drag in the arrangement to make a time selection, then select Insert Blank from the right-click menu. To get rid of the time selection press Ctrl+R or click anywhere with the normal select tool.

@Zynewave wrote:

Oooh, we need to coordinate our efforts. I’ve spent the day rewriting the toolbars chapter (offline). 😳

😳 indeed! It looked like you were updating chapters in the order they appeared, so I thought I was safe starting somewhere in the middle! 😆

If you announce in a post here if you are going to revise a certain chapter, then we could avoid doing double work.

I’ll do that – but maybe a new topic (in the VIP lounge?) would be in order as to not bump an older preview thread. For now, I’ll try to replace all old screenshots I can find.
Thanks for the link to the conventions page.

I’ve replaced the screenshots in the getting started chapter for now. It guess I don’t have enough permissions in the WIKI to replace or delete images, so I’ve appended the date to the new ones.
I also mistakenly uploaded a wrongly named image (start_new_project_2010_07.png) – please delete. 😳
Tell me if it’s acceptable. I can also work through the many out-of-date images in the guide if you’d like, if that saves you time.

I’m reading my way through the getting started chapter, and I feel it desperately needs updated screenshots that actually show the things described (track toolbar, + track button, track menu button, + effect button, etc.) and don’t irritate new users with things that look differently than what they’re expecting. Us users could help out with updating all the pictures throughout, I guess, if we agree on some standards. It will still result in some minor inconsistencies like different device names, though. :-k

Something that struck me is the top button on the new project page – of course we’re used to it, but I think it actually has a high potential of causing confusion or making the user uncertain of the correct choice. Since it seems only relevant to plug-ins (audio I/O is configured separately anyway), here’s a suggestion for an alternative: 😉
Put two of those little check buttons below the plug-in database button, reading “Mono/Stereo Plugins” and “Surround Plugins.”
The top button could still be used for an option to “create from template…”

If the “new default arrangement” is not configurable in any way (I don’t think it is), why not call it a blank or empty arrangement instead. Might be more descriptive than default.

A little correction: “The layout and edit options of an editor are defined by an editor profile.”

After inserting an effect, you’ll notice that the new effect appears below the + button. This brings us to an important principle in Podium: The signal flow follows the visual layout of the track hierarchy. Audio starts at the bottom of the track hierarchy and flows up through the effect chain on the track, continuing up through effect chains on group tracks and the master track, until it arrives at the master output at the top of the master track.

(As far as I can tell there’s no introduction to group tracks, so I’d add something along these lines here. Feel free to rewrite or scrap it!)
Let’s create a group track to illustrate this. Add a new track using the method you’re most comfortable with, and enable “Use as group track” in the track properties dialog before clicking OK. You can move any of the other tracks you’ve already created into the group by dragging them onto the group track’s header in the tracklist (Or why not in the mixer? Nudge, nudge. :wink:).
All signals produced on tracks inside a group will flow up through the group track, thereby being affected by its level and pan settings, as well as any effects inserted on the group track.
Tracks placed inside of groups are termed child tracks. The view of all of a group’s child tracks can be collapsed by clicking the collapse button in the top left corner on group track header, and expanded again in the same way.

Next, let’s add a mixer bus. A bus allows you to extract audio from one or more tracks using a bus send, and then inject the mixed bus output to one or more tracks using a bus return.

Ctrl+Shift+Alt+Space – Wow, is that a secret 30-hit combo finishing move!?

Ahem… Sounds good to me. 😉

Since this happens to me in other sequencers/hosts too (with the same plug-ins), I’d say the first place to ask would be the developers of those plug-ins it doesn’t work correctly in. If they turn out to be totally oblivious to the problem, maybe there’s still a chance for Frits to fix it. 😉
So far I pointed FabFilter to it – did you already write Image-Line, reFX, and D16?

Here’s a link to a related thread in which Frits offers a little technical info: http://www.zynewave.com/forum/viewtopic.php?t=2093

@Zynewave wrote:

I tried the Volcano2 demo. I also read the comment from fabfilter in the topic you linked to.

Clicking on the plugin Window frame to give the plugin key focus works fine. Podium receives key press messages from Windows (WM_KEYDOWN/WM_KEYUP) and distributes these to the plugin with the editKeyUp() and editKeyDown() VST messages. The plugin can then respond to the key press and return to the host whether it “consumed” the key press. If not consumed, then Podium checks the key for Podium key shortcuts.

It appears that the when you activate the Volcano plugin editor by clicking inside the editor window, it consumes the WM_KEYxxx messages, which then is never received by Podium. I read their comment about the mousewheel focus, but I can’t see why this should prevent them from letting the WM_KEYxxx messages through to the Podium parent window.

If this works in other hosts, then it could be because these hosts parse keypress messages before Windows distributes the messages to the key focus window.

@Zynewave wrote:

@thcilnnahoj wrote:

@Zynewave wrote:

If this works in other hosts, then it could be because these hosts parse keypress messages before Windows distributes the messages to the key focus window.

Is this not recommended, then, or something you’d rather not do?

I believe the way I’m doing it is the standard way to respond to key messages in Windows. I prefer to keep to the norm, to ensure compatibility with future Windows versions.