Zynewave's Forum Page
Forum Replies Created
-
ZynewaveKeymaster@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.
ZynewaveKeymaster@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?
February 10, 2007 at 11:12 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.February 9, 2007 at 14:38 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.February 9, 2007 at 14:10 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.February 9, 2007 at 13:37 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.ZynewaveKeymasterPlease send me a minimal project with automation tracks and loop range set up to recreate the problem.
ZynewaveKeymasterThe crash seems to occur because the Podium memory pool gets corrupted at some point during scan of a FL Studio plugin. Debugging did not help in determining exactly where the crash occurs.
But I think the crash occurs due to multi-threading conflicts. Podiums scan procedure is running in a separate thread, and it appears that IL plugins are messing things up if some plugin functions are called from a thread different than the UI thread. Question to thockin and koalaboy: Are you using Hyperthreading or Dual core/processor PCs? If so, you could try to configure Podium to use only one processor. That got rid of the crash on my system: Bring up the Windows Task Manager, locate the Podium.exe process, right click, select “Set Affinity”, and ensure only processor is selected. This setting is not remembered, so quitting Podium will restore the full affinity mask.
I have modified the Podium scan procedure, so that all plugin calls are done from the UI thread. Hopefully that will also fix the reported issues with scanning of Betabugs plugins. Fix coming up in 1.80 release.
ZynewaveKeymasterI downloaded the latest FL7 demo version (which includes a bunch of Imageline VST demo plugins). I get a crash upon import of one of the IL plugins AFTER one of the main FL Studio dlls have been imported. I tried renaming the plugins to reorder the import order, and it crashes no matter what plugin comes after the main FL VST. Weird :?. I’ll do more experiments tomorrow.
ZynewaveKeymasterCouldn’t the same thing be achieved by adding a group track ‘above’ the two VST tracks, and just assigning the single midi input to that ?
It won’t work, although I can understand why you think this could be a solution. However: everything flows upwards in the hierarchy. So a MIDI input assigned to a parent group track will only flow upwards to the nearest device mapping, and it will not flow downwards to any child devices.
January 30, 2007 at 22:56 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.ZynewaveKeymasterImplementing plugin MIDI out streaming will require several days of work, so I don’t consider it a minor feature.
I have a small todo.txt where I write stuff I need to implement before starting on major features. It seems that every time I almost get this list erased, some issues discussed on the forum gets added to the bottom. It’s been a while since I last did something “fun”, so only bugfixes will be added to this list in the coming weeks.
ZynewaveKeymasterNot possible yet, and it’s not coming until after I have implemented SRC/time-stretching.
ZynewaveKeymaster@soundquist wrote:
Another variant:
1. Create a loop.
2. Let it loop. Deactivate the loop during playback.
3. Audio drops out when the cursor reaches the end of the (now deactivated) loop.
/SQ
Confirmed. I’ll look into this the coming days.
ZynewaveKeymaster@soundquist wrote:
@acousmod wrote:
How would you want it simpler?
With the workaround that you describe, I have to select the group, right click and choose “unbundle” (or the key command), then Ctrl-click the clip I want to ungroup and re-apply the key command, with the danger to accidentally click somewhere and deselect the clips that were part of the group and having to re-select each of them. I know by experience that this scenario can happend in the action !
The bundle seems like a really great feature, but I agree with acousmod about the above.
The risk of losing the whole bundle seems not far away, with the current way of doing things.
If you happen to accidentally deselect all the events in the unbundled event selection, you can always just press undo to restore the previous bundle.
Perhaps it would be a solution if Ctrl-click would de-select individual events from a bundle, instead of the whole bundle. It would then be possible just to press Ctrl-N to create a new bundle without the de-selected events.
I think it would be more consistent if ctrl+click affects the entire bundle. I may add a “Remove this from bundle” command to the right-click edit menu.