Topic: Loading Projects from templates

@Conquistador wrote:

Maybe I have missed some of the points here (sorry) but I like the current set up for Projects and I think it works well…

The problem here is that when you create a new Project it does all that but when you save a Project using “save as” it doesn’t create a folder – it just creates a new pod file. This is rather problematic for several reasons – not least because the whole point of creating a Project is it comes with a folder for the management of associated media elements. The current implementation potentially undermines that organisational principle.

In fact the current implementation of “save project as” to me is closer to a “save Arrangement as” than a “save Project as”. Maybe it would make more sense to just have (as I suggested long ago) the making a Project something that is done at the start as a “container” for a number of Arrangements (based on that Project template) and that any “save as” refers to Arrangements, not Projects. That would hopefully resolve this long standing confusion.

I understand it now. Thanks for the illustrations aMUSEd 🙂

I think I will highlight these two quotes of yours that I agree with as well.

Maybe it would make more sense to just have (as I suggested long ago) the making a Project something that is done at the start as a “container” for a number of Arrangements (based on that Project template) and that any “save as” refers to Arrangements, not Projects. That would hopefully resolve this long standing confusion.

It might require a lot of work (hopefully not) but either way it sure would be a huge step to simplifying this aspect of Podium.

imho a “save arrangement as” command should place a new Arrangement into the existing Project folder but a “save as” for Projects should create a whole new Project folder along with assigning the Project a name etc. There should ideally also be a dialogue for collecting or duplicating associated media (Reaper has something like that in its save dialogues)

Looking at your images I have to agree with this as well. :-k

@Zynewave wrote:

Let me bring in an old post by acousmod from another topic:

@acousmod wrote:

One more thing that is not really related to events names, but that could benefit from it : you have based the audio events names not on the file names but on some chunk inside the files.
The problem is that some softwares that create wav files does not write this code, so the files appear in Podium with no name at all, which is quite unusual…
Another problem is when we rename a file in a Windows explorer and that Podiums of course shows a different name.
So, together with an event name parameter, I think that it would be good to base the names of audio events on their files names like in any other host I know (the same for the Project names that appear in the Previous projects list).
Perhaps that you had seen some advantage to base them on special internal code, but the only result I see is that introduces potential confusion…
Why not make things simple ? 😉
Thanks !

That makes sense to me, and for a long time I’ve had the intention of locking the project and sound names to their filenames.

Can you describe some cases where you would want the project or sound names to be different from their filenames?

If you want more information in the project name than what you want in the filename, then you could alternatively use the project stickie note to store the extra information.

This is true as well – really I’m not dogmatic about this as long as there is consistency and it makes logical sense. To me the overall organisational scheme is where the problems lie.

@aMUSEd wrote:

To me the overall organisational scheme is where the problems lie.

The issue with “save project as” and other file management features, is something I’m going to revise at some point. These issues are however not directly related to the question of how project and sound names should be handled.

Druid, are you there? Given these pros/cons of having separate project and sound names, it’s time for your closing argument 🙂

@H-man wrote:

Now,acknowledging that the program hasn’t asked for any other input, how safe you feel about clicking Save Project?

The original project is of course safe, Podium/windows will force a folder verson (ie. H-Proj1_01) however you still have your second H-Proj1.pod file that you’re stuck with, regardless of whether you change the Project name or not.

I’ll make the project properties dialog pop up after you’ve created a new project from a template. With the name label now reading “Project name (used as filename when the project is saved)” it will be more obvious that you’re entering the filename. Note that the project is not saved at this point. The “New file:” path shown in the project start page shows the eventual file location when the project is saved for the first time. You can change the project name repeatedly before you save, and the “new file” path will change.

@H-man wrote:

@aMUSEd & Conquistador – You may realise but I would point out that an auto-save feature (if implemented) won’t work to well with Save Arrangement as… workflow. Cloning an arrangement before changing it would be the only option here.

Who hasn’t overwritten a document accidentally working this way?

I doubt I would ever feel safe with an auto save feature anyway

@Zynewave wrote:

Druid, are you there? Given these pros/cons of having separate project and sound names, it’s time for your closing argument 🙂

*shakes* Oh the nerves, put on the spot..! 😀

I was in bed; I’m in Australia so that was my sleep time you were expecting me to respond in!!! :frustrated: 😉

Alright, well… First, the current system works for me only because based on previous experiences I’m pretty careful about filenames and saving. I’m used to cases where things are different and it gets confusing. (Vaguely connected, as to what was said before, I often turn off auto-save features myself; I see their use but they scare me because I’m not the one who does it.)

The reason I’d like to maintain it as separate is probably the same reason I’d like unicode support; aesthetics. Which is not a good reason to keep it that way if you want to change it. To me, filename and project name are entirely separate, but that’s just how I work. Not everyone will understand that so easily, and not everyone in music has as much computer background as me. And then there are individual differences, too!

I guess, in short: I don’t mind. You’re quite right; stickies can be used (can I just say how happy I am that I don’t need to use a VST for notes now? I’m so happy with that feature). As long as I can change the project name, I’ll be happy. I’ll admit that I pretty much call the filename and project name the same.

The place where unicode differs is that I like to call folders by kanji, so my music folder can read as 「体現」 instead of “taigen”. Currently I use junctions to allow me to use whichever I want, depending on unicode support of program. But I guess that’s for another thread. 🙂

I don’t mind; I just wanted to raise those issues. Realistically, the only ability I want is to be able to rename projects, which inevitably will mean I want to rename the file, too. So I’ll let everyone else debate the issue now. I’m sure I’ll manage with however it turns out. 🙂

p.s. I wrote too much. 🙁

Thanks for the input everyone. I’ve uploaded a new 2.21 preview/beta so you can try out the new project/sound name behaviour.

Druid, I pondered your wish to call folders by kanji, and then decided to go against you on this one :P. I’ll let you have the final word on another future feature 😉