@wanyze wrote:
I’m wondering if there is an official thread, timeline showing on what date function x is planned to be implemented. It doesn’t need to go too far into the future, maybe just a simple plan for the next 6 months or so?
I prefer to work without the restraints of a timeline. I tried in the past to maintain a list, but discussions in this forum often resulted in a change of course and turned that list upside down. I like the peace of mind of working with a feature until it is ready, and not have to rush it out because I made promises on the forum.
I’d like to know if if there are functions like Timestretching planned at all, and if we can expect them in the next 12 months to be implemented? What are the next features we’re looking into?
If you keep an eye on the posts from me on this forum, you will get a sense of what I am working on. As I’ve posted recently, I’m currently experimenting with SRC/time-stretching, so that feature should hopefully appear within a couple of months.
It would definately feel like there is any development happening and some security to see podium is alive and healthy, and future versions to look forward to. The worst thing is if it feels like an abandoned product with no future hope and too slow development, which i think many people are scared of (like some other hosts).
I hope that reading the posts in the release and future forums should reassure you that there is plenty of development going on.
Nice suggestions. Currently I’m working on audio features. I’ll get back to improving the editors after that.
Hi,
1) Agreed. It’s already on the future plan.
2) You add more bus instances to the project with the menus of the devices panel on the project start page. You add tracks with bus send and return mappings just like you do with any other type of mappings. You can insert a bus send with a single drag action. Take a look at the video tutorials in the wiki section for some hints. Dragging in a send mapping does not automatically create a track with the return mapping if not already present. This is something I plan to implement in the future.
3) On each track with a bus send mapping you have a gain and a send dial. The gain dial controls the amount of “dry” signal that continues upwards in the track hierarchy. The send dial controls the amount of “wet” signal that is sent into the bus.
4) The current example projects require that the user installs a selection of freeware plugins. I also would like to have full example projects included with Podium. I just need to create zSynth, zSampler, zComp, zMaster…
Only allowing resizing to the left when no phantom copies exist would make it easier. I’ll keep it in mind.
Note that you can resize to the left if the event is set to start beyond the start of the sequence. It’s only below the 0 position on the timeline that is restricted.
The reason it doesn’t resize to the left, is because it cannot extend into negative time within the sequence/sound. To make this work, all events/waveform data within the sequence would need to be shifted along the timeline by inserting a blank segment at the start of the sequence, and this could affect other phantom sequence events referring to the same sequence. It is a more complex operation than just extending the tail of the sequence. Some day I’ll probably add support for it, perhaps by showing a dialog asking if you want to add the time at the start of the sequence/sound.
I understand now. You can’t record directly on the child tracks. You need to do the recording on the parent track, and then move the recorded clips to a child track, after which you can record new clips on the parent track.
Edit: I replied before seeing your latest post.
Frits (can I call you by your name).
Sure. I won’t even complain if you should misspell my name with a z (which quite a few do :wink:)
I still need to figure out how to have several MIDI tracks controlling the same instance of a VSTi, but I haven’t read the manual much nor looked at all the tutorials. This is possible, right?
You mean an insert instrument (and not multitimbral)? It should be doable by placing all the MIDI tracks (without any mappings assigned) as child tracks of the VSTi track.
Also, did I understand right that if I for example set up a multiout VSTi with tracks for insert FX for different outputs I can save that as a “preset” and load that part of track setup to other projects? This would help quite a lot.
I assume you are talking about the “Track template” feature. Currently these can’t be migrated to other projects. If you create an extensive set of track templates you can save it all as a project template for new projects.
But surely you intend to add more MIDI editing options at some point after you get some more audio related stuff done?
Yes. More advanced quantize options are high on the list.
Shift+Ctrl is the shortcut for selecting the vertical zoom tool.
But after thinking about it, I could change the behaviour to mimic the way selection works in standard Windows lists: If you hold control while clicking a file/icon, it’s only at the release of the button that the selection is toggled (if no drag action has been started). This way you can hold control and start a copy drag action without toggling the selection. Is that the way to go?
@spritex wrote:
Editing events.
To make sure I understand you correctly: The problem you experience is that inserting/editing events that are within one second ahead of the play cursor is not heard until the next loop cycle?
This realtime response can be improved, but it will require a few days of work. Currently I feel my time is better spent on some of the more essential features that have been discussed on this forum recently.
@spritex wrote:
@Zynewave wrote:
To achieve the ‘gap-less’ performance, Podium prepares the playback one second in advance before outputting the prepared buffers to MIDI and audio interfaces. This is why e.g. edits applied to events within one second of the current playback position will not be output.
This is one of the first things I noticed when I started testing Podium yesterday. It’s a bit annoying when you are editing a drumloop or whatever.
If it can’t be gotten rid of, would it be possible to make an option to change this from 1 sec. to a shorter time sacrificing CPU cycles of course?
Hi spritex,
Are you talking about realtime response to loop range adjustments or editing events?
