Thank you very much, Paulie Phonick. Posts like this are very useful for me, you know...Paulie Phonick wrote:Great tool, quintosardo.
If you could imagine how long does it take to do this...Paulie Phonick wrote: Actually, I've been thinking of writing a similar thing myself, just couldn't get to it because of my studies...
Disk streaming is done in "idle" cycles. So cpu load indication is not so significative (the most of the load is on hard drive and is done out of "process"). But the pc is hardly loaded, this is why I try to maintain a good "focus" for this vsti -> it is more for good multitrack playing, less for loop-manglingPaulie Phonick wrote: I just gave Traks a try and I get ugly clicks on playback - the more the higher the Sound setting, though they don't stop when Sound is set to 0. The clicks are there at 256 samples latency, but disappear at 1024 samples. As the CPU load doesn't even hit 25%, I think the problem is related to disk streaming - my laptop drive is not the fastest around. Still, as I know I never got any clicks when streaming in sfz, I know it's doable so maybe the streaming procedures need some optimisation. Also, an option for buffering samples entirely in RAM (as long as there's enough space) would be nice.
Avoid using sliders while playing or try using less tracks...
I believe that it is an "overload" problem, not a bug. I'll try to optimize the code.
You CAN load loops entirely in RAM!! Simply define as "sample" instead of "loop". Today it is limited to 2.000.000 samples, but it is only to avoid huge-unwanted-loading (if you switch a note from "loop" to "sample" it is automatically loaded in ram. If it was a 10 min loop it is a big problem)
Yes, already in todo listPaulie Phonick wrote: Apart from that, I'd love to see the following features in Traks:
1. A file browser on the GUI instead of dropping.
I'll add this if I'll see that it doesn't overload sound part... I still hear clicks when using sliders while playing...Paulie Phonick wrote: 2. Horizontal and vertical zoom in sample display.
I agree, it is not intuitive. A solution maybe keeping the length while moving the start after the endpoint. More complicated solutions, like reverse playing, are not suitable, because it involves buffer pre-loading and so on...Paulie Phonick wrote: 3. Ability to select a range on the sample and quick assign it to a note by MIDI learn. Also, currently, the user is forced to assign End point before the Start point, which is not particularly intuitive. I'd say a better idea would be to allow any order of assigning and highlighting values in red instead of playing the note when Start is not before End. Or better, play sample backwards then.
Yes, this is interesting. It will be added together with visual feedback from gui keyboardPaulie Phonick wrote: 4. Ability to quick assign detected sections (white marks) to notes by MIDI learn.
These are a step further. The original idea was: you have multitracks, maybe pre-assigned to notes, and you simply want to play them, without worrying about file cutting and tempo and pitch and so on..Paulie Phonick wrote: 5. Ability to edit detected sections - combine sections, move boundaries, split at position.
In "todo" list: attack+decay for slicesPaulie Phonick wrote: 6. ADSR envelopes (for each section?)
ADSR would be only for single shots, right??
Already in "todo" list for samples, together with multi-samples (velocity+random switching)Paulie Phonick wrote: 7. Polyphonic mode for playing multiple sections from one sample at once.
Please note that today "samples" play poliphonic over "loops". While a loop plays, you can add samples (in that demo I added single shots to get variation to the same loop)
Thank you again for your reportingPaulie Phonick wrote: That's all that came into my mind after my first look into Traks. I'll be happy to drop further ideas or do some further betatesting, as you develop Traks. Thanks for making it free!
Quinto
