@Zynewave wrote:
Is it the same VST parameter number(s) that gets recorded both when using the morph pad and the quick buttons?
If so, then I’m guessing the problem lies with the way that Kore uses the VST BeginEdit/EndEdit commands to notify about parameter changes. These commands are used to allow the host to ignore automation playback as long as the user has grabbed a control in the plugin. That it works in Acid could be because Acid ignores the BeginEdit/EndEdit system. Just guessing. I also read in your linked topic that NI responded with “This is a known bug of Kore 2 and will be hopefully fixed with a future update”.
Yeah but later on someone else from NI states that a fix is hard without breaking AU compatibility (for some reason) so it might be a long time coming. Clearly though Acid is recording something (even if it’s due to Acid not sticking to specs – that would be ironic)
Yes it does use the same param ID (you can see in the picture for comparison I recorded some button presses then a stretch of smooth morphs to check this and it uses the same envelope for both – e.g. one is designated param 21) – there is a demo version if you want to investigate (you won’t need the hardware – you can replicate the button presses by clicking on the square as opposed to dragging between them)
thanks
Yes I am. I really meant it just ignores them. So do most hosts but as you can see Acid manages it somehow and just using normal automation (in touch or latch modes).
Just to help explain the problem here is an image of Kore 2:
http://www.spincity.nl/images/Kore2_Composite_white.jpg
The Morph pad is the 4×2 rectangle that records 8 states (patch variations) and enables one to morph smoothly between them using either the mouse of the hardware controller. You can also snap instantly to a square using mouse clicks or button presses (you see the buttons on the Kore hardware – each corresponds to a square).
Most hosts including Podium can record the smooth changes between params in the Morph Pad (whether done with the mouse or hardware) but apart from Acid all the rest cannot seem to record the fast snaps using the buttons or mouseclicks approach. Fast snaps are useful in performance though as you can use them as fast patch changes or for more dramatic effect than the smoother changes.
Kore uses standard VST (host) automation to send information to the host – not midi cc (although it can do that too) if that’s any help.
@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.
OK so this is my Podium Projects folder – all of these folders are created when you make a new Project and each of them contains subfolders for Arrangements (i.e. they function as containers for Arrangements and media files associated with Arrangements – as they should).
However when you use the “save as” to give a Project you are working on a new name (say if what you are working on has gone in another direction you want to capture but without overwriting the original Project) it just saves a new pod file and does not create a project folder or give it a proper Project name etc and it places it at the same level as an Arrangement, not a new Project.
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)
@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.
@Zynewave wrote:
@druid wrote:
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?
Well, :(, those are some of the reasons why I originally made it possible to have project and sound names independent of their filenames. But unfortunately this flexibility has frequently been a source of confusion. Most people don’t want to maintain two names for the project, and so often ignore the project name, which in turn leads to the confusion when working with several revisions of a project.
Renaming the project/sound files will change the project/sound names.
Do you feel this simplification is a step in the wrong direction? Other users care to comment?
Yes I think it might be – that’s a good point and I also raised some doubts in the other thread – I think what is needed is not for the Project name to follow the filename (as many people would prefer descriptive project names anyway) but when you “save as” for it to ask to name the Project when at the moment it just asks to name the file (I presume when you create a new Project the filename follows the project name – it should not really be the other way round).
What should probably happen is when you want to save a Project with a new name is it brings up a version of the Project Properties dialogue.
I think here we need a clearer signal too – shortcuts like ctrl click are fine if you are the sort of person that remembers such invisible things but I need visual cues like a button or rightclick command to arm automation
Ah yes I’ve just noticed that. I think your proposal is sound for now (although the crucial thing surely is what Podium considers to be the Project name – even if the recent list reflects the filename surely Podium will still have given them the same name?)
However all the same I think there is a good case for looking at this in more depth at some point – saving versions of work in progress is very important to me
@H-man wrote:
hmmmm …now it is creating the folder 😕 Where’s LiquidProj3ct when you need him? 🙄
@Zynewave wrote:
I can. If for example you have created a template called “Sketches”, then each new project you create on that template will be called “Sketches”, “Sketches_01”, “Sketches_02” etc.
I’ve noticed that the Project folders will auto version due to Windows not liking two folders of the same name at the same level, but the Project Names in Podium’s Recent Project List would be Sketches, Sketches, Sketches unless you change the Project Title to match.
But that’s just splitting hairs really, it’s pretty intuitive to manage.
If the program creates the folder for the .pod file and arrangements then that’s the desired result.
May the best thing to do would be to disable the “Save Project as…” 😉
This is why we need a “save arrangement as”
(but don’t get rid of “save project as” since at the moment it’s all I have to save versions of work in progress)
I know this isn’t a priority but at the very least can you fix it so that when I save a project using “save project as” it gives it the name I saved it with in the Recent projects window so I know what I am opening? (I seem to end up at the moment with half a dozen projects all with the same name even though the filenames are different).
Great thanks
Oh well eventually I found why the blue colour I had set midi notes to had reverted to grey and it’s a good example of what I was saying about bits of layout/config stuff being all over the place. While you create midi note colours in the setup/colors panel (it seems to use the same box as param gradation – or is it level meter? – I have them the same – also confusing) I found that setting had been overridden by another one that you can only get to once you have recorded some midi and rightclicked on an empty space in the piano roll – “Piano roll region properties” – which has a box to colorise notes with track colors.
Then you have some texture and dye panel options in preferences and another set when you create a project, plus all the layout settings in editor profiles – it’s things like this that really should be unified into a consistent set of controls that can be saved together.
@soundquist wrote:
@aMUSEd wrote:
Settings for layout and appearance (like with colour) like that should be storable somewhere and easy to return to
I think you can in the “Save complete setup…” and “Load setup…” in the Setup menu.
But I agree perhaps the warning message should be “Do you want to save your current setup?”.
I’m not sure exactly what is saved in the Setup file. I think it is only editor profiles and colors, not MIDI and Audio setup. I looked in the Wiki, under Setup files, but there was no information there, as far as I could see.
I don’t know – like a lot of the project management aspects of Podium it’s a bit confusing with various aspects seemingly handled in different ways. I didn’t even know of the a save all settings command and even though I had saved my colours I find for some reason the colour I had set my midi notes to (here) had reverted to grey after doing this even though I had it shades of blue so the whole system needs simplifying and unifying.
It’s just an inconvenience and I was able to redo them but it does concern me that this might not be the last time this happens and really it should not happen. I did not expect it to completely trash all my settings till it popped up a warning and even then I thought they would still be in the older project file but it wiped everything. Settings for layout and appearance (like with colour) like that should be storable somewhere and easy to return to and I think a program should offer users a certain level of reliability in maintaining their data.
@druid wrote:
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.
Yes – although it would be better if such settings were saved somewhere.