Page 4 of 5

Re: The Ideas Collection

Posted: Wed Jan 30, 2008 9:32 pm
by dahnielson
Consul wrote:Well, I'm a moderator, and I'm able to split topics, but I can't figure out the interface, and I'm afraid of messing something up. I created a new thread here to continue this discussion:

viewtopic.php?f=5&t=20
AFAIK,
phpBB documentation wrote: Rather than just merging topics together, you can also merge specific posts into any other topic.

To merge specific posts into another topic, start by locating the selection menu beneath the topic, and get to the Moderator Control Panel. From here, you need to enter the topic ID of the topic you want to move the posts to. You can click Select topic to see a list of the topics available and specify which. Select the posts which you wish to merge from the current topic, into the existing topic. The posts merged into the new topic will retain their existing timestamp (e.g. they will not appear at the end of the topic they are being merged to, but will be sorted based on their timestamp).
From here.

Re: The Ideas Collection

Posted: Fri Feb 01, 2008 11:56 am
by dahnielson
To get slightly more on topic than off, what I want to see from LS...

* As I've mentioned elsewhere: being able to "freeze" instruments, unload to free up RAM and reload them with just a click on a button.

* An DSSI plugin version (and LV2 whenever that spec is finalized).

* Ease of implementing new sample formats (which I understand was the motivation behind the modular approach). Today, for example, it makes more sense to me to create an instrument in the SFZ format than as a GIG.

Re: The Ideas Collection

Posted: Fri Feb 01, 2008 1:10 pm
by sbenno
dahnielson wrote:To get slightly more on topic than off, what I want to see from LS...

* As I've mentioned elsewhere: being able to "freeze" instruments, unload to free up RAM and reload them with just a click on a button.

* An DSSI plugin version (and LV2 whenever that spec is finalized).

* Ease of implementing new sample formats (which I understand was the motivation behind the modular approach). Today, for example, it makes more sense to me to create an instrument in the SFZ format than as a GIG.
with freeze you mean like Kontakt does ? you play a midi file and the sampler remember which notes and layes were triggered and unloads the parts that are not needed ?
what happens if a non cached note is triggered ? silence of loading from disk and thus an artefact (click, dropout) ?

Andreas is already working on a DSSI plugin :)

About formats I fully agree, GIG is nice to access widely available sample libraries but the future lies in modular formats.

cheers,
Benno

Re: The Ideas Collection

Posted: Fri Feb 01, 2008 1:30 pm
by dahnielson
sbenno wrote:with freeze you mean like Kontakt does ? you play a midi file and the sampler remember which notes and layes were triggered and unloads the parts that are not needed ?
what happens if a non cached note is triggered ? silence of loading from disk and thus an artefact (click, dropout) ?
No, no, not at all. It was someone else that named it that after I had described it (on the mailinglist?). What I want is to be able to with a click on a button disable an instrument, that will unload the samples from memory, but let the instrument keep its place on a channel, and then enable it again to get the samples loaded back into memory.

Nice if you are tight on RAM but really want one big orchestra template while you bounce each section to an audio track.

Of course the next step would be to group instruments so that you could disable/enable them at once. Which is handy if there are extra non-keyswitched articulations for some sections making them requiring more than one channel.

Re: The Ideas Collection

Posted: Sat Feb 02, 2008 8:19 am
by cuse
Yeah, a "suspend" / "resume" button on the channel strips. I like the idea. I put it on my TODO list. Shouldn't mean a lot of work.

Re: The Ideas Collection

Posted: Mon Feb 04, 2008 9:23 pm
by Alex
I'm no coder, but i can see a modular setup, given Jack's power and useability, as a big plus.
Easy enough to write a startup script for everything, even for a code dummy like me.

Alex.

Re: The Ideas Collection

Posted: Mon Feb 04, 2008 9:28 pm
by dahnielson
The thing I really long after is the ability to implement performance scripting inside the sampler and not as an external application.

nki, exs, fxp formats

Posted: Tue Feb 05, 2008 7:42 pm
by MisterBark
Hi there ;)

Actually, most of the sample libraries are in nki and exs format.
Even if I/we love the giga format, we must see that this format has unfortunately no future ! :cry:
The most realistics samples are in the libraries of tomorrow, and they won't be in gig.

I think it's time to seriously think about an implementation of nki, exs, fxp, etc.
Is it really impossible ? :)

maybe nki is copyrighted, but fxp ? or others...

Thanks for your anwser and happy to join you today ! 8-)

Re: nki, exs, fxp formats

Posted: Tue Feb 05, 2008 8:07 pm
by dahnielson
MisterBark wrote:Hi there ;)

Actually, most of the sample libraries are in nki and exs format.
Even if I/we love the giga format, we must see that this format has unfortunately no future ! :cry:
The most realistics samples are in the libraries of tomorrow, and they won't be in gig.

I think it's time to seriously think about an implementation of nki, exs, fxp, etc.
Is it really impossible ? :)

maybe nki is copyrighted, but fxp ? or others...
The exs and fxp shouldn't be any problem to reverse engineer and implement, and the new engine is supposed to make it easier to add new formats. In the meantime I'm working on a translator. The problem with nki is that you are likely to go insane before you've managed to reverse engineer it. I believe that it in fact is encrypted somehow.

Hopefully the future lies in Cakewalks SFZ when it comes to open formats.

Welcome aboard!

Re: The Ideas Collection

Posted: Tue Feb 05, 2008 10:58 pm
by sbenno
the default NKI format is just a zipped XML (with a few bytes binary header).
Only kompakt/kontakt based sample libraries (sample library + bundled sampler) are encrypted.

The problem is NKI has more features than GIG, more sample mangling functions, scripting etc
so creating an engine which can render most NKI samples correctly would be quite a bit of work.
If we create own new and flexible engine we can make advances much faster and we could write a converter
which although not always 100% correctly, could convert samples from NKI to an LS format.

The goal is that at some point LS will set the standard and not vice versa :)