PiginiThe only reason I chose not to implement selection of the track, is to avoid moving the current track focus when you just want to drag objects around. If you use the “auto-assign” MIDI input option you would probably not want the MIDI input focus change when you drag around objects.
and thats a good reason. makes perfectly sense to me.
I think the need to select the insert tracks will be greatly reduced when I implement popup object selection in the mixer. You won’t need to select the track to access the objects in the track inspector.
another reason why the selection is implemented in the right way in 1.86 already.
or have I missed something here?
I haven’t changed the device definition import menus. They will only be shown if Podium finds any definition files in the expected Library folders. Check that your library folders are intact.
Prob solved, had some old pathes in the registry.
Are those registry entries actually necessary? Could be all in the podium.ini and even that ini could be in the podium-folder, if it was up to me. That way there were no leftovers in the registry when podium for some reason does not get deinstalled completely, no clutters in the system. How about just a selfcontained folder with everything in it?
PiginiDepends on the mixer view. Sometimes there is not much space to click on.
But now that you know where to click it’s hardly a prob, is it?
Giving up the possibility of dragging all kind objects in the mixer would be such a shame, and btw inconsistent. Since dragging ojects around everywhere is one of podiums main strength and allows for so many different work flows.
You can use the filter tabs at the left, if you need more space to hit it, that should do the trick.
PiginiThe track is not selected because you click on an object which you then can drag to other tracks. I’ll consider changing this behaviour so that the track is always selected, even when you click on an object.
I think, it behaves as it should, plenty of space to hit the right spot. dragging objects to other tracks is a very nice feature which I would not sacrifice.
The mixer looks superb to me. (I’m wondering how Lawrence likes it now)
Another QUESTION:
Have you put the “Import Hardware Definition” somewhere else?
I can no longer find it in the Devices menu(first screen, used to be below “Import Plugins from folder”).
[edit]
okay, prob solved. managed to import it by just importing the hardware definition via import file menu. but better keep that change in mind for the manual.
PiginiI’ll probably look at it when I begin implementation of control surface support. Hopefully within this year.
Yes, I guess such a systematical approach is better than jumping between parts, adding requested features all over the place. In the end we get a more stable and bugfree app.
I’ll keep that in mind.
Thanks, I’m looking forward to this. 🙂
PiginiI must say, I don’t miss track numbers in podium, though I’m completely relying on them in another app, but that is because that app would just not work without them.
If track numbers were to be implemented into podium, it would best fit podiums hierarchic approach if the tracks were not numbered initially.
Better have a button or point in the menu for starting the numbering/renumbering everytime you want to have your tracks (re)numbered. That way the track numbers would actually mirror the hierachy(track numbers/subtrack numbers/ sub-sub…and so on) without the hazzle of doing a decent numbering initially in the middle of the working process.
The option of not renaming them with the new numbers, but putting the number like an index in front of the tracks name could be practical too, that way one could have Custom names and track numbers at the same time.
PiginiI am more likely to use EXT 2 as a plugin chainer within Podium, a very powerful chainer that would be.
Exactly what I thought.
And I’m glad Podium got me focused to actually being productive again, instead of “test-toying” around.
PiginiFunny how many users around here seem to have an energyXT-license.
Forgot to mention, I hold one too. Grew tired of the neverending beta-story and the bug hunt, though. Too many features too soon and many new bugs before the old ones are fixed. Hope, Jorgen gets that sorted out one day.
But to get some music done I needed a reliable quality host and feel very comfortable with Podium now.
Another host , I found very likable in the past was the good old Muzys (wish its muzynth existed as a vst). Too bad, the developer sold it to some company, which obviously just let it die. It’s still usable to some point. There used to be a free version with the CM-Magazine. The followup Luna is not yet as feature rich, but is a good simple slim host to start with.
Never liked the bloated commercial “Big Boys Hosts”.
PiginiTotally agree with psylevation. Podium’s reliability is just great.
It feels solid and the whole concept is logical, no clittered messy features around that look knitted on.
I use it mostly for hosting my vst’s and putting preproduced midi bits together, mixing and rendering the audio, using several midi-networked computers. That’s what I bought it for and I’m absolutely happy with it.
For generating the basic Midi-Bits and peaces however, I’m back to running my old Atari-Sequencer Omega2 from Dr. T’s in an Emulator(Steem). It has so many nifty midi-features, which I found nowhere else.
My general impression is, that todays vst hosts, while being more or less linear DAWS and Mixing consoles, are all lacking considerably in the Midi-Department and the choices for different (nonlinear) workflows are very limited.
After all, the best prog to use, is the prog you know best, as far as it is bugfree and stable of course. What Omega2 became for me in generating and manipulating Midi parts, is Podium going to be for everything else in producing audio and putting the bits together.
However, I have high hopes that Frits will improve the Midi-Possibilities in Podium after the more important general DAW-related things are done. But not everything possible needs to be implemented and one has to take into account which features actually integrate best into Podium, and which should better be left to plugins or even other more specialized apps (like arrangers, algorhytmic composers and so on).
PiginiPiginiVery useful, but it would be a waste limiting that “cut into pieces”-feature only to cut notes into quantized values. By that, you only get values which you could create using other means already (though it would be a very efficient additional way).
But why stop there?
The main advantage of such a function could be to get pieces, which are not archieved so easily by other means. Things like getting the equivalent of triplets, just with other denominators. Put 5, 7 or 9 beats evenly spaced into a quarter note and so on.
One could have it both ways. When selecting that feature while quantization is on, it could behave as you described it, with quantization off, like I mentioned.
PiginiThe “export stuff” to an external library is probably something I’ll look at in the distant future, but currently there are a lot of items that have a higher priority.
Take your time, there is so much on your list already.
But then again 😕 … Maybe I should not have called it “export to library”, it only sounds like a nice but “nonessential” feature.
The option to save selected midi events as a small midi-file would be enough for a start.
Drag and drop or one point in the selection context menu, either would do.
Importing midi files as parts (sequence events) is possible already, even with drag and drop, meaning half the work involved for a “songeditor” is already done.:wink:
edit:
On second thought:
It doesn’t even have to be an actual selection for the export.
It could be just a selected sequencer event, readily cut with the scalpel tool. That way it would be exactly the reversed process of importing midi files as sequence events into tracks. Would that minimize the work involved?
I got a bit carried away when thinking about the perspectives. That might have put too large a scope on it.