Topic: Preview 2.34: Minor consistency updates

@Zynewave wrote:

@LiquidProj3ct wrote:

Frits, I’ve problems with master bouncing. I wanted to do an small intro for a track, so I used Ctrl+A in arrangement view to select all clips and I moved them 8 bars towards right, then I did the intro.

However when I was bouncing it the intro always was silenced in the final audio. I finally solved it, and maybe you could consider it a bug, the problem was that the first tempo event was displaced too, and bounce don’t render anything that is before the first tempo marker.

I don’t think it was the tempo event that was the problem. When you use the Select All command, it currently selects all events, including the hidden bounce events. When you then drag the selection, the bounce event will be moved too. I think that is what happens. I’ll do some tests. I think I’ll change the Select All (Ctrl+A) command so that it does not select hidden bounce events.

Question: Should Select All be changed so that only selects events that are available in the editor? For example, in the arrangement editor it would not select events that are on tracks hidden by a collapsed group, or a disabled track tag.

Hmm, it depends. Not selecting tracks hidden by tags sounds good, but child tracks on a collapsed group track… Maybe it’s a misunderstanding, because they’re very much available in the arrangement editor, even when minimized, no? As for bounce events – I think they should be moved just like the underlying sequences, whether activated or not. Otherwise it will only become confusing when you reactivate the bounce later on (without rendering again). I think that there should, however, only ever be one bounce event on a track, and it should always span the entire arrangement length. It has lead to some confusion before when bounce events were suddenly ‘split’ in two, or didn’t render some bars anymore (as in this case).

Also, real-time bouncing acts like normal recording, as in it only creates a sound event at the point of recording – this is mostly expected, and might save disk space, but you can’t switch from real-time to offline bouncing without first disabling bouncing on the track completely. It’s fine if you know it (and you usually won’t switch modes, I guess), but if switching to offline bouncing was to fill in the gaps automatically, it would eliminate another obstacle to trip over.

@Zynewave wrote:

Alright, I think this is another side of the problem we discussed some time ago in this topic:

http://www.zynewave.com/forum/viewtopic.php?p=16942#16942

Maybe the time has come to finally fix this bug 😳

One solution would be to create an effect track exclusively for bouncing, as you also mentioned in that other topic. On that “bounce” track you would then not be able to assign an effect. That simplifies the technical difficulties with the bounce/effect routing in my code. It also means that the bounce point can remain at the post-effects position, even when you add effects to the chain. The question is: Should this bounce track be made invisible for the user, or should it appear in the chain panel like it does today?

If it is to be visible in the chain panel, I could make it a proper “bounce selector”, which when clicked will show a menu with the bounce options (same as the current track > bounce submenu). You’ll also be able to drag the bounce track up and down in the chain panel to position the bounce extraction point. I think I’m in favour of the bounce selector. Opinions?

I’m all for it! I agree that it should definitely be visible (and touchable), and I’d say it should also light up with the bounce color when it’s active.

Oooh, how I look forward to test this for bugs. 😆

While translating the manual I’m seeing that it seems my C++ manual I read one year ago… everything are ‘objects’ and ‘events’. This is the right way to name the ‘objects’, though, I think it would be wisest name them by its functions, as we can read in the most of manuals, ie:

Instead “note event” just “note”
Instead “track object” just “track”

It would ease a lot the reading since it will seems more ‘close’ to regular people. What do you think about it?

I haven’t seen ‘track object’ used anywhere yet.

Me neither, I made up that ‘object’ while writting last post 🙂

if we don’t want to list inputs, outputs, device mappings, presets, and parameters every time

Why not? I see other calling them inputs and outputs, ie: http://flstudio.image-line.com/help/html/app_wiz2.htm

best regards 🙂

@Zynewave wrote:

Let me know if you find a description of a standard. I also call the main return key for “Return”, and the enter key on the num pad for “Enter”. But when I look at the menus in various Microsoft applications, they all show the key shortcut as: “Properties Alt+Enter”.

Well, it looks like ‘enter’ is often used when any of the two keys can be pressed, due to their similar function.
You could try if shortcuts in those MS programs also work with both keys, in which case it would be called correctly.
Since the Enter key doesn’t work for shortcuts, but controls playback most of the time in Podium, it might be better to use Return in shortcut descriptions, too. :-k

I’ll revert to calling it Return in the guide chapters I already did, at least when it’s used on its own.

Also, Alt+clicking doesn’t unassign auto-assigned inputs.

Edit: Also also, what about the source/track menu mixup (the last fixme remaining)?

I think both ways are fine, that Alt+Click remove auto assigned input or doesn’t