Hey Frits. I have my final Windows 7 64-bit 7 days early, having access to suppliers is great! 🙂
I haven’t tested Podium 2.22 yet, nor much audio stuff, but I plan to give them a quick run soon. Just letting you know that I can at least test briefly any 64-bit Podium you make now. Not sure if that’s useful to you right now or not, but there it is.
I wouldn’t be able to heavily test as I am outside of the constant music work habit at the moment. But I can definitely test specific things, especially, running it to see if it works! 😛
Don’t start me, I’ve been discussing W7 64-bit drivers with Tascam, and they say they’ll “consider” it AFTER it’s released. Talk about pre-planning. And I read up on it; in most cases, it’s very similar to Vista, so it wouldn’t take them a whole lot of effort, and I’m sure they don’t need to go down the shop and buy it to make drivers, because Microsoft surely have programs to help driver production to be ready for release.
Not to mention, that their “64-bit support” 32-bit drivers (whatever THAT means) don’t work for me, so I jumped back. Note that the drivers are 32-bit, it’s just that version’s release notes only stated 64-bit support, but since it was latest version I thought I’d try.
Anyway, 64-bit drivers will be a headache I think. I hope driver production for 64-bit is taken more seriously with Windows 7 than it was with Vista.
In other news, I’m now looking forward to seeing if Podium goes 64-bit. 🙂 Not sure what benefits it would really bring though, so I don’t mind either way atm.
Strange, when I tested, by default it metered the FX I added, if I recall correctly…
Well, never mind. As thcilnnahoj said, if the mixing grid is on, you can just click the square appropriate anyway, without having to go through menus.
Right click on the mixer “track” (Battery 3) and then go to “Meter” and see which it is selected. If it is metering only “Battery 3”, then any FX after this will not show. If you select in that the last FX in the chain, then the meter will use them all.
Let us know if that fixes your issue.
Also, don’t forget you can set the fader this way too, allowing you to choose how far in the chain you want the fader to affect volume!
Well, though, as I said, if you move/copy podium.ini to the installed Podium folder, it should read it from there instead, meaning you’d only need to except the one folder for Podium (as long as that’s the only file it loads).
For Windows XP, it’s in any folder view in explorer/my computer, under “tools->folder options->view tab->show hidden files and folders”.
And the solution I gave, as in, the folder (typically c:My Documents & Settings
Glad you got your problem sorted but as I said, I’d recommend shifting the ini file to your Podium folder, meaning you only need to make one folder exception. There are still all the other .ini files, but they are just colour setups so you won’t need to automatically load them on startup. I also moved my templates and whatever else folders, usually in the Documents folder, to the Podium folder and relocated them in the Podium setup, so that it’s all contained in the Podium folder. If only files being loaded on startup matter, this won’t affect you, but I prefer it so I recommend it anyway. 🙂
Could it be the podium.ini file, typically located in the user folder, under Application Data/Zynewave? If you copy that to the folder you installed Podium to, as I understand it, Podium won’t look for it outside of the Podium folder, however it will still load it from that file, which will be “external” to the .exe.
As for any other possibilities, I’m not aware of them, but anyway, that’s my suggestion, and I’m glad too, because I hate programs that save options in the
Are you sure it’s nothing to do with 64-bit or Windows version? Just checking.
That I”m aware of, drivers being 64-bit is different to applications being 64-bit. As long as the drivers are stable (and that’s hit and miss with some developers, but should unify after Windows 7 gets more widespread in the user sector (in my opinion!)), you should run 32-bit applications just fine and use all the VSTs you did before (there might be some that might use certain functions that don’t work properly or at all? Not sure…). 64-bit applications, on the other hand, typically don’t load 32-bit plugins, which is frustrating.
I’ve read that plenty of users are fine with 64-bit drivers and 32-bit applications, both in Vista and Win7.
For some time to come, I think there will still be the occasional incompatibilty/weird bug that will make 64-bit less desirable, but I don’t think many users will experience this. I’ll be jumping to Win7 myself in a few months, along with a new computer, and am hoping it will be a smooth ride.
Eh? Oh I wouldn’t expect you to do that! If you get around to unicode support, that’s when I’d expect it. It’s alright; you would be with the majority of English/ASCII speakers (ASCII speakers? Hahahaha.) that don’t really recognise the importance and wonderfulness of unicode. I wish unicode had been there from the start, but English had the game on before anyone else in computers. 🙂
I humbly refuse to have any final word on anything. As long as you remain consistent (unlike another that I have had grudges about), and you’ve got a wonderful track record while I’ve been around, it’s your project and I can only make suggestions!
I’ll actually probably get used to project/sound filename-name linking so that I prefer it, so it’s all good.
@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. 🙁
What happens if I wanted to change the name of a project, as I often do when I wantto write something but have no title for it at that time and just write a temporary one?
What happens if I rename the file? Does it change the project name as well, then? If so, does nobody want the ability to save different project and file names? What if, for instance, I wanted to use a colon in my project name? What happens then?
You can save color setup (colour for me! :P), or complete. The problem with saving complete setup, of course, is that if you load the new one, it will overwrite it with more or less exactly how you had it before, defeating the one of the purposes of loading the new default (which really is for one of two things; if there is corruption or other problems, to fix it, or to get the new features/default layout to keep up to date).
I would recommend to anyone to, before loading a new default layout, or even before upgrading, load up the old version of Podium, or the version of the interface you are using currently, and save complete setup to your own .ini file. That way, you can always reload it if you need to. There may be changes to the .ini file in some versions though, but still safer than assuming, though I agree it’s often expected that programs will do this gracefully. I guess that’s one of the negatives to Podium’s updating style, which is little bits here and there over various places, with no “cycle” or large version update plans. That of course also has positives!
I’m going to guess you are not “amused” by this! 🙂
I’ve had a look at the podium.ini file, and it DOES record which version of Podium it is. As I suggested before, the old and new versions could be detected and the changes made to the new one only for what had changed since the old one. I’m sure it would still reset some settings, but it wouldn’t have to do them all.
In actual fact, someone else could write an application that does it… I’m incredibly tempted, but I haven’t programmed for years, and I’m in my last semester of university, so I guess I’d better not.
If someone reminds me (assuming I don’t remember myself) in 3 months, I could *try* to take a look at it and produce something. No promises, though. Would many find such a thing useful?
Then unfortunately you will have to either imitate the new layout by setting it up yourself, or you will have to remember your changes (or write them down!) and load the new default and make the appropriate adjustments.
@Zynewave wrote:
For the 2.21 release I’ve renamed “load default setup” to “restore default setup” and added a “restore default editor profiles” command. That at least enables you to restore all the editor profiles without affecting your other settings.
Much appreciated! I don’t alter that much of the UI, so at least for me, this will help fix most of the issues I experience when loading the UI. Ideally, it would be cool if Podium knew which version the .ini came from, and then adjusted only what was changed between that version and the new; but now that I’ve written this, don’t worry, I don’t expect nor even really want you to do this. It’s too fiddly and quite time-consumingly silly, and I’d much rather you work on other things! Your 2.21 suggestion should solve, in my opinion, the most annoying difficulties.
H-man: I haven’t used it yet, but I have a feeling now that it’s put in front of me like this, I might just use the embedded editor too. I never knew I was so easily manipulated by presentation of software! It’s quite surprised me…
Markus: Save as is in the menu; although I would like a ctrl+shift+s for save as, if only to match other software, since it seems to be fairly standard.
Your plug-in scanning request has positives and negatives, and I both agree and disagree with you. On the one hand, I don’t like having to add it manually myself to projects when I add a VST to my folder, nor reload it if the layout and its internals change considerably. On the other, though, I don’t like the idea of load time; some people have heaps of VSTs and it would kill them to have it load every time. I did like how XT did it; it would read each folder, and since I organise my VSTs into subfolders, it didn’t take long to load each menu. It was sort of like a compromise.