Conquistador's Forum Page

Forum Replies Created

Viewing 15 posts - 796 through 810 (of 1,598 total)

← 1 2 3 … 53 54 55 … 105 106 107 →

September 10, 2007 at 12:41 in reply to: Preview: Compact track layout #10810

Conquistador
Participant

@Zynewave wrote:

Command types:
What will be the commands in these menu buttons…exactly, if I may ask?
What kind of “commands to move tracks and replace an entire chain of effects”?

This menu shows all groups that are on the same level as “Drums”. Selecting a group will move focus to that group. This is similar to the old popup menu that temporarily was removed in the 1.94 release, due to the inspector redesign. The bottom submenu is a quick way to reorganize the groups, as an alternative to collapsing and dragging the group tracks. Clicking the menu button for the “Drums bridge…” chain below will show a similar menu for the tracks within the drums group.

This menu will be extended (probably in a later release) with submenus for recalling template tracks. It will be similar to the existing template track submenus, but will allow replacing the entire chain of sends/effects with alternative “channel strip” templates. Eventually I’ll add support for saving these templates to file, instead of storing them locally in the project.

Sub Menus…
Ok I can see that clearly now. Thanks. I do think that while the idea is clever and desirable IMO (read nice work here)…too many sub menu’s are not a good idea. I have a much wider idea for Podium Navigation that will massively simplify it IMO, but I need to do a full mock up to properly demonstrate it at some point in future.

Slider!
Also you continue to add GP features but no slider. The panels are very difficult to navigate with 5 tracks or more in the GP and the mixer raised even a little.

But that problem is bigger now because I *really* like the Large transport and just love the way the mixer slides up from behind it and slides back down out of sight, smooth, smooth very smooth design and implentation. Great.

But…combine the large transport, the GP with 5 tracks or more visible in it and drag the mixer up less than half way and panel access is “locked”. You will not be able to open any of them.

A simple slider in the GP solves this problem.

GP Vs Arranger:
IIRC you said in compact mode one will not be able to drag re order tracks.

” The new compact mode offers an option to reduce this space. What you loose is e.g. the ability to freely drag effect tracks horizontally to a specific group level. You’ll need to use the group panel for these kinds of edit actions.”

I do not think this is a good idea. In Compact mode the arranger is losing a basic yet very important feature. Ease of use in the GP should not equate to a more complicated experience in the arranger.

You are risking a new user thinking that drag re – ordering is not possible in the arranger…I say this because “Compact Mode” will have to be activated by default to really be effective for new users. This is surely the “mode” they will be initially (by default) be presented with, no?

Also you are asking a user to always use the GP in compact mode (this I agree with to a point) but that also means he has to switch between the arranger and the GP just to drag re – order tracks.

The inspector should be a mirror (within reason) of the arranger track level features, not result in the loss of any arrangement features.

By all means add features into the GP (which I still think is unique in a very good way) but do not remove arranger features. If messing up the hierarchy is your worry (which I can understand) then perhaps another way round this problem can be found.

Podium in the new ‘easier’ mode will require using two views instead of just the Arranger or GP. That is not easier, that is harder IMO.

September 10, 2007 at 11:29 in reply to: Preview: Compact track layout #10807

Conquistador
Participant

Yes 😉
But I suppose that there are other less obvious things for us that have made Frits choose this way.

Of course there is always that possibility. He sees things from a developers perspective.

I don’t know if the zGrid plugin would have solved the “muted track automation during record problem” and other difficulties related to the bottom position in the hierarchy of the audio tracks ?

No idea. Time will tell.

We have better to wait until there is a beta of the new track system

Yes being able to actually use it should shed more light on the changes but I do not want to use a beta version of Podium on my current PC.

I will wait for the stable finished version. Frits’ ability to test his products seems better than some public beta’s. But if he wants to release a beta…I will have to wait for testing to finish before I use it. I cannot risk any problems with my current set up.

Because it is not part of the branch that is shown in the group panel. I first selected the level track under “Drums Bridge Loop” to make that branch appear in the group panel, and then selected the master track. This is how the group panel has always worked.

Sorry, just too many changes to visualise. It might be clearer once your changes are tested and ready.

Going into details about this would be too exhaustive, but rest assured that these changes to the track layout provides a better solution than zGrid, on all accounts. Some examples: My screenshot shows only one plugin in each of the three chains. So placing a zGrid plugin in each chain would not result in fewer tracks. Instead using a zGrid instance would add an additional layer of plugin assignment. First you assign the zGrid instance to the track, and then you assign the desired plugins in the zGrid editor. The concept of a chainer IMO only has benefits for complex serial/parallel routings of multiple plugins. Simple serial chains of plugins are much easier managed with the channel strip templates I mentioned in my previous post. Another major drawback with the zGrid/chainer approach concerns automation. Since zGrid would be a VST plugin, it is not possible to dynamically expose the VST parameters of each configured plugin within zGrid to Podium.

Then perhaps that is the problem. Why does it have to be a VST? If that is the only way to get various FX to show on the same track in Podium (in the arranger) then a VST it has to be.

I wish I could suggest some development ideas that other host have used but that is simply beyond my scope of knowledge currently, so if the Z Grid idea is that problematic to implement and as result very low (if at all, anymore) in your list of priorities then there is not much point in discussing it in this thread.

To automate plugins within a zGrid instance you would need to use the zGrid editor to assign the desired VST fx parameters to a set of generic parameters that zGrid supports. These generic parameters can then be automated in Podium, but the parameter objects would then not have the actual VST parameter names.

I see your point but other hosts can pull this off without the need for a VST chainer. In any case were going round in circles regarding the zGrid. It does not look like it will happen anytime soon (if at all) so as you probably prefer, lets just put the whole zGrid idea to one side.

If your GP ideas are indeed better then lets see when it is ready. Once you release a beta (if you still want to do that) I assume those that are interested in the beta will download it, test and provide feedback on this forum, so I will simply keep track of that until it is ready.

September 9, 2007 at 20:57 in reply to: Preview: Compact track layout #10799

Conquistador
Participant

@Zynewave wrote:

So if one has parameter tracks for a Guitar Instrument track, various FX parameters (automated delay, another for a filter) all of these will appear below other tracks at the bottom?

No. They will appear immediately below the guitar track. Imagine if you created an automation track for the zPEQ in the screenshot. In the modular mode this will be shown as a child track of the zPEQ track, i.e. above the “drums bridge loop 1” audio track. In compact mode all automation tracks within the “chain” is displayed below the audio track. The automation track for the zPEQ would then be shown as e.g. “1 Freq (zPEQ)” with the controlled effect in parentheses. Acousmod recently posted a topic where he requested a possibility to have all effect automation tracks displayed below the source track, so that the source audio file is shown as backdrop in the curve editor.

Thanks for the detailed explanation. That is much clearer thanks.

Other things to notice in the inspector is the separation of tracks into chains, each with a menu button for selecting a different track in the group and for accessing commands to move tracks and replace an entire chain of effects using templates.

Command types:
What will be the commands in these menu buttons…exactly, if I may ask?
What kind of “commands to move tracks and replace an entire chain of effects”?

Level meter:
The “Level” parameter from the “Drums” track does not show up in the GP in your first screen shot…why? It is not hidden in the arranger so why is it hidden in the GP?

“Drums Bridge Loop” Parameter track has a Level parameter track that is visible in the GP and the arranger…the Pan track (minimised in the arranger) is not visible in the GP…why is that?

zMaster on the Master out:
Ready or work in progress?

Food for thought:
I do think the changes seem to make some things easier but…the questions I have do raise some concerns about complexity creeping back in…maybe I just do not understand it properly yet. Anyway I think once you answer those questons things might be clearer.

Sorry I have to say this…
I do think some of the GP changes are a step forward, however Frits I really do think that simply giving us the ZGrid would have saved you a huge amount of development time.

You would IMO (of course I could be wrong) surely not have had to work so hard to simpify the look of the Group panel *and* the arranger. You could have just developed the ZGrid instead.

With that plug we would have had no need for so many recent changes to the GP and the the arranger. We would have had a chainer built in that would have brought track levels down massively.

I would guess you could have then moved straight on to timestretching as well. Or addressed the Auto mapping issue which IMO is still a very big problem even though I do think it is an unforseen problem.

I don’t mean it to sound like you made a mistake but even with all the changes you are making here…especially since you said…”There is still plenty of work to do on this, so I don’t know when it will be available.” I cannot help thinking the zGrid is (even now) a simple solution to the problems you are trying to solve here. I would guess most of us might be happier to wait for that instead.

Any new user would be up and running with the ZGrid very quickly. The chainer concept is immeadiately familiar…the GP and the arranger in their current and future designs…are not.

The new changes are better though, but they look somehow like a very long way round to solve track count and complexity issues with the hierachy.

This may be just my opinion of course but….does anyone else agree with that?

September 9, 2007 at 16:11 in reply to: Preview: Compact track layout #10795

Conquistador
Participant

Ok some thoughts…

@Zynewave wrote:

I’m working on a major update of the track layout. There is probably going to be a new option in the arrangement properties dialog to select between a new “compact track layout” and the existing “modular routing track layout”.

I think that is a good idea.

The compact layout will hide a lot of the complex hierarchic features, and offer a simpler track layout and a simpler set of commands for managing the tracks.

What exactly will the compact mode hide? Sorry I need to know in a bit more detail if possible.

You can also consider the compact mode as “simple” mode and “modular” as advanced mode.

That makes sense.

The goal is to make the compact mode foolproof, so that it will not be possible to mess up the hierarchy, which can happen for inexperienced users in the modular mode.

Good idea and very important.

At any time can you switch between the modes in the arrangement properties. The compact mode is only a different visual presentation of the underlying modular routing.

Ok good.

The compact mode will also display all parameter tracks as child tracks of the bottom audio/instrument track in the chain, even though they may control plugins on tracks further up the chain.

Hmmm…not sure if that is “easier” Frits. Surely IMO it is easier to have the tracks shown under each of thier parent tracks, not under all of the parent tracks at the bottom of the GP or Arranger?

So if one has parameter tracks for a Guitar Instrument track, various FX parameters (automated delay, another for a filter) all of these will appear below other tracks at the bottom?

If so multiply that scenario by 5 instrument tracks and the collection of parameter tracks at the bottom is simply more complication IMO. I really do not think that is easier which is what the compact mode is of course created to acheieve…ease of use.

So this is a case where the displayed hierarchy is slightly different from the routed hierarchy. This is more similar to how automation tracks are presented in other hosts.

Sonar displays automation overlayed on to the same track. One can choose what automation parameter they want to see on the track at any one time.

Cubase 4 IIRC has separate automation tracks but they are under each of the tracks being automated. That I think was how I last saw it in Cubase.

As you can see in the screenshot below, the group bars for the hidden track lanes with fx mappings are not shown.

Ok…

1. The ZReverb is hidden on the Drums track in the arranger and…

2. The two sends (Send 1 and 2) and the zPEQ are hidden in the Drums Bridge Loop 1 track in the arranger…

Correct?

What about the Drums Chorus 2 Loop 1#2 and the Drums Chorus Loop 1#3 tracks? Why are they not visible in the screenshot assuming the master track at the very top is the currently selected track?

Certainly from your screeshot it looks like the Master track is the currently selected track in the GP. No?

Those hidden tracks must be accessed through the track inspector, which will become more central when using compact mode.

I like that idea.

The bottom “Level” track is shown with only three parent track bars to the left of the lane header, as opposed to modular routing mode which will show all nine parent track bars.

So which mode is visible in the screenshot? There are nine bars visible in the GP “Modular mode” and only 3 parent tracks in the arranger. So compact mode is only for the arranger View?

Other things to notice in the inspector is the separation of tracks into chains, each with a menu button for selecting a different track in the group and for accessing commands to move tracks and replace an entire chain of effects using templates.

This in theory sounds like very good news if I understand it correctly.

September 9, 2007 at 14:48 in reply to: Preview: Compact track layout #10791

Conquistador
Participant

@acousmod wrote:

All of this seems very good indeed.
But it is hard to imagine how it works without trying…

Good luck Frits !

Yes my thoughts exactly. I can see you are trying to simplify things while keeping the power and flexibility of the hierarchy but some of it is just over my head. I have some questions and ideas but I need to try and visualize what you are saying first 🙂

September 8, 2007 at 16:13 in reply to: Free full version of Independence!!!! #10788

Conquistador
Participant

@Zynewave wrote:

Get it before the server falls over….

Maybe it already has fallen over. I get an “Error because of misconfiguration.” message when I try to enter the YellowTools site.

I got my share of errors as well Error 500 e.t.c but…to my surprise all I had to do was simply refresh my page until it started to load (took a bit of time) but it did load…from then on it was a bit less busy but simply refresh any page that gives an error.

I had to do this a few times with some pages, several times with others and some times got straight through first time with some pages…

..I suppose one could wait until it calms down a bit but I would rather get my copy now 🙂

Just refresh the pages…it worked for me. 😉

September 7, 2007 at 21:13 in reply to: Auto-Save plus visual confirmation. #10781

Conquistador
Participant

@Zynewave wrote:

Will this also be the case when saving without using Keyboard shortcuts?

Yes.

Thanks.

September 7, 2007 at 08:22 in reply to: Auto-Save plus visual confirmation. #10779

Conquistador
Participant

@Zynewave wrote:

@haiku wrote:

sounds like it’ll just blink when you use the keyboard shortcut so you know it worked – right?

Right.

Will this also be the case when saving without using Keyboard shortcuts?

September 7, 2007 at 08:18 in reply to: Auto Device mapping problems #10778

Conquistador
Participant

@Zynewave wrote:

It’s going to be a post Podium 2.00 task. I’ve got my hands full with the track layout changes.

Thanks for the feedback. At least I now have a rough time scale for a solution to the problems raised in this thread and when I can hopefully return to those Projects in Podium.

Some clarification:
The objects you see on the project start page device list are a direct reflection of the actual objects in the project. The tracks only store a link to these objects, so deleting the objects will automatically remove the object references on the tracks

Thanks for the clarification. I thought that might be a possibility but of course the problem still remains, but you have have kindly given me a rough timeframe for a possible solution and I will definitely look out for that solution post 2.0.

It will be interesting to see how Podium develops between now and then (as usual), so please do keep your focus on the features you are currently working on if adding a possible solution to this problem now will sidetrack you (of course this has happened before, sorry), or is just too much work right now in addition to GP refinements, which are of course important.

Hopefully some of the suggestions rasied in this thread can aid your implementation of a solution after 2.0’s release.

Cheers Frits.

September 6, 2007 at 17:58 in reply to: Auto-Save plus visual confirmation. #10773

Conquistador
Participant

Frits, it might be better if you provide a screenshot to avoid potentially re doing all your work after 1.95 is released.

Better to revise while you are working on it as we all seem to have different views on it.

It would also let me possibly see if there is any progress on the Device set up idea I suggested as a solution to a rather large problem that is of course now very well documented

September 6, 2007 at 13:54 in reply to: Auto-Save plus visual confirmation. #10769

Conquistador
Participant

sounds like it’ll just blink when you use the keyboard shortcut so you know it worked – right?

That does sound like it but I just wondered if Frits would clarify. In any case we will see soon enough.

September 6, 2007 at 07:49 in reply to: Restricted to Podium license owners

Conquistador
Participant

This content is restricted to Podium license owners.

September 6, 2007 at 07:29 in reply to: Auto-Save plus visual confirmation. #10766

Conquistador
Participant

@Zynewave wrote:

I’ve added a save-confirmation blink to the project name written in the top title bar.

Nice addition. Thanks.
But how exactly would this work? Would it blink if any changes are made to a project and stop when changes are saved?

Or would it blink a few times once you have saved a project to confirm it has been saved?

September 6, 2007 at 06:38 in reply to: Auto Device mapping problems #10765

Conquistador
Participant

This is just a summary of the changes I think have to be made…but I have also made mention of an idea I think will solve this problem, add unique functionality to Podium while hopefully making things easier for Frits to implement these changes by extending existing functionality…more on that later in this post.

Suggested changes
1. Auto re mapping of any FX and instruments: If any FX or VSTi mappings are still active on tracks and one should delete their VST list or layout of plugs in Devices: area once Podium is directed to the current VST folder it should…

a.Scan that folder

b.Auto re map all lost mappings from an arrangement (or prevent mappings from being lost in the first place by allowing a VST layout to be deleted from the Devices: column without also deleting track mappings). It can be done as every other host out there I have used operates this way. Sorry Frits it is a major problem in it’s current state IMO. It just gets worse when more projects are created.

2. Allow for global project wide VST settings: Currently any changes are specific to a project. While that is useful an option to allow changes made to a VST list / layout to extend to any other projects or to replace any other project VST list / Layout is a far better and frankly already a standard feature in every host I have used. Live, Tracktion, ACID, Cubase Sonar e.t.c

3. Automatic updating of Audio input / output mappings when an Audio device is changed from within an existing project: If one should start up an existing project with Audio input output mappings from an older device still visible in the Devices: area then go to MIDI/Audio interface > Audio > ASIO interface to select a new device…Podium should automatically update the Audio input output mappings that are visible in the Devices: area on the Project start page.

An idea as to how you might implement these changes…

Save Device Set ups.

I noticed that Track templates are like snapshots of part of an arrangement that can be saved and recalled into any other arrangement (within the same project). Perhaps Podium could take a snapshot of the VST layout or list for a Project that could re called by a user in any other project.

I am guessing here that the VST layout or Devices: mappings must be a separate entity (to a degree anyway) from track mappings to avoid removing them from tracks if they are deleted from the Project start page.

So perhaps instead of just allowing a user to “Save VST layout” I think allowing a user to “Save Device set up” with all current mappings (Audio input / Output, Busses FX and Instrument mappings) might make things easier for you to implement these changes. That is a guess of course, but I am just trying to help you as the developer here, as you do encourage and respond to ideas.

Currently in Podium we can already save Complete set ups or Colour set ups. So why not Device set ups? You could add a “Save Device Setup” command to the Setup Menu.

How would this work?

A user sets up a default template with all the changes they want. That saved Device set up is then saved, ready for recall into any older project that needs updating. This kind of implementation also preserves the per project mappings approach that Podium uses, so it would maintain it’s flexibility here.

Ironically I don’t know of any other host that has per project VST settings so I see no need to lose that, but of course changes must be made to address the problems raised in this thread IMO. Using the “save Device Set Up” approach would I think solve those problems.

I do also think one should have an option to make Device set up changes per project or extend to any Project. This is crucial.

So you choose “Load Device Set up” from the Setup Menu and you are then asked if changes are Per Project or for All existing projects. This could also be a global setting maybe that we could set and forget.

Another advantage of this approach…

It would not just automap or auto update hardware and VST settings in any project it would even allow a user to have multiple saved Device set ups. For instance users like jpleong could have one saved Device set up for Office another for home and a third for mobile usage e.t.c

Of course we should be able to name the saved “Device set” up whatever we want to as well.

Thoughts?

September 3, 2007 at 19:45 in reply to: Auto Device mapping problems #10759

Conquistador
Participant

@kingtubby wrote:

I’ve probably got this wrong – and it wouldn’t be the first time 😉 – but I have a default project that I keep updated with plugins and so on. If I go back to an older project that has become outdated I just copy the old arrangement folder to the current default project and resave. It seems to work for me, but as I say I’ve probably missed some crucial point here…

Mart.

Good idea… (and I do make use of default projects):wink: but if I already have FX and instrument mappings on tracks in the older project (using your example) then I will lose those track mappings (from the older project) if I tried out your solution with a new default project.

Also if I have already spent a huge amount of time arranging the midi and audio data, automation e.t.c into a finished composition in the older project I would have to start that all over again.

How, using your solution would you avoid those issues?

Viewing 15 posts - 796 through 810 (of 1,598 total)

← 1 2 3 … 53 54 55 … 105 106 107 →