Am Dienstag, 15. Januar 2008 18:57:54 schrieb Luis Garrido: > > The idea is to really natively compile an engine after it has been > > created or edited within such a module editor. So the editor would act as > > a > > A big problem I see with that approach is one of interactivity, which > happens in other SMS too. The response time of such a system may be > important. Having to wait more than a couple of seconds to hear the > results every time you add or remove a new module is not for everyone. > How RT responsive do you want the design process to be?
Well, I'm not sure if I get your point. On one hand you fear a modular approach would be less efficient when being interpreted, ... on the other hand you fear a native compiled modular approach would be too sluggish while being recompiled ... and yet another time you prefer a monolithic engine? Who sais you would have to restructure & recompile an engine at first place? If you're fine with a monolithic engine, then you could simply stick with one (or couple ones) precompiled. Noone would force you to touch the engine / module editor. You could still stick with the common instrument parameter editing part of the instrument editor, that is the instrument parameters you are used to from "normal" sampler implementations, unrelated to the modular design. So I'm not getting what your concerns are. And about the RT-safeness of a compiled modular approach: let's stay realistic, one would seldomly touch the structure of a sampler engine or recompile it, and I doubt somebody would ever even need to do that during life performance. And it's clear that you cannot have both: maximum performance AND RT safeness while adjusting the engine structure. So it's clear we would have to make a decision which one of both we prefer and I'm sure max. performance is more desirable by most users. > I don't know if that's a very strong argument, anyone who cares about > performance enough to consider tweaking compiler flags can build her > own monolithic package or just run Gentoo. Not everybody can do that. You have to admit that there are people who are more admired and capable of technical tweaking and there are a lot of people who are not. > > The randomizing capability already exists in the gig engine as a "Random > > Yup, not very hot, IMO. I am thinking more of slightly randomizing > pitch, vibrato, filtering, etc. Which you "could" do with the existing engine as well. Your concern is that everything is mapped into the dimension system, thus not being very intuitive, right? But in that case it would be sufficient to just add a more convenient dialog or wizard into gigedit where you could directly assign the randomness to a certain parameter, which would afterwards automatically be applied to the actual dimension settings. We won't need to touch engine code for this. But of course you are right, I'm aware of Kontakt's concepts, and of course directly setting rules to ONE certain parameter is much more intuitive than having to deal with a confusing dimension system. But I definitely won't use a dimension system again in a new engine. :) > You can of course use midi controllers > for this. I think the VSO library provides a midi filter to enliven > performances by cleverly inserting cc messages in the original midi > stream before it reaches Giga. But it would be convenient if the > randomizer was integrated in the sample engine (i.e., the cutoff > frequency of the LPF is not constant, but is generated randomly > according to a certain statistical distribution within bounds.) I And what kind of distribution functions did you have in mind? Could you elaborate please? CU Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
