1 Unlimited subfolder nesting - For instance soundsets - Drums - 808 or Soundsets - Instruments - Pianos - Grands and so on.
2 Unlimited individual soundsets within the soundsets folder- Indvidual soundsets instead of a complete bank like SF2 is better because of the small memory footprint.
3 Custom file extension - A standard file format like SFZ is good but the ability to change the file extension.
4 Soundset scan - If a soundset cant be found scan for it.
5 Drive change - The ability to move soundset folders and then reconfigure an installed plug.
6 Code input - A code input into the sample engine so that custom file formats could be written and standards like REX could be used.
7 Output per key - Perfect for recycled breaks and drumkits
Sample mapping (For creating samplers and sample drum boxes)
1 Mapping from the plugin interface - Needed for sample loading and placement.
2 Archivability - Many free standards are around now for compressing audio data (Tracktion has this down to a tee)
3 Looping from the plug interface - So often used it isn't even worth giving an example.
4 Destructive editing - For normalise functions and so on
5 Ability to send to EXE - Good for sending samples to Soundforge or whatever for editing.
Straight playback features (Needed by all)
1 Looping
2 Velocity layers
3 Multisplits
4 Loop sinc
5 Unlimited bit rate and sample rate full stereo
6 Timestretch (Leave till last)
7 Reverse
I'm sure theres more so post em 🙂
Tom7777 ·
Woah dude i think you said it all right there 🙂 the only thing i can think of if to allow shorter wav file lengths than is curently possible in SM.
lalo ·
😮 😮
🙂
crossfading velocity-zones/key-zones
lalo
Nu Audio Science ·
Dragability - The ability to drag samples from the plug to the host, And the ability to drag from the host to the plug.
skOre ·
I guess key and velocity things will depend on how you use NASs suggestions above, don't think that it has to be implemented directly...
Tom7777 ·
My friend make music and are interested in sound also and we all have different apps and im subscribed to various audio mags. I have had the chance to test various things out such as NI Reaktor which uses more than one sampler module and is what i think SM should do also for the different suggestions. One thing it also has which has not been said yet is a granular/particle sampler which i think would be very cool.
Tom7777 ·
Have the basic sample playing module, Multi sample module, and then versions of these which do loads of extra crazy things in both normal and granular modes.
Nu Audio Science ·
I like the idea of the seperate components, Put the code input on all of them so we can write beat slicers and granular and so on 🙂
Tom7777 ·
Yeah thats a great idea NAS. Im not totally sure on what reaktor does but i think that things change via what values are input to the modules so for pitch if a negative number is entered it gets reversed and plays backwards ect.
Nu Audio Science ·
Cut and copy wave display - This would be something along the lines of Acids Beat Chopper, Basically the ability to resequence a sample, It sounds a lot more complicated than it actually is 🙂 , I'm probably wrong but i think it coud be achieved by having a playback position control.
Tom7777 ·
Yeah that would be cool, sample length should be a float output on the modules i think, then we could do all types of crazy stuff with maths and feedbacks.
Shifrin ·
It's a very interesting idea guys, you seem to have covered most bases with the various suggestions! Would be interesting to see what malc/jorge think about this? Although I do realise it could be quite some time before something like this happens!
Shif.
Nu Audio Science ·
Yeah i would think V2 or something 😉
I have to be honest the quicker the better for me but the way they have put SM together so far shows they know what to do and when to do it so no rushin 🙂 .
jorge ·
Shifrin wrote: It's a very interesting idea guys, you seem to have covered most bases with the various suggestions! Would be interesting to see what malc/jorge think about this? Although I do realise it could be quite some time before something like this happens!
I was thinking about this earlier. I think a lot will be possible just by exposing array ( or memory pointer which is the same thing ) as connectors going in and out of the code component. The existing wave file component would be changed to just output a pointer to the wave memory. The code component could then be used to create a very flexible wave player that could play the wave once and stop, or loop, it could play 1 sample per sample, or 1.5 sample per sample, or count up and down, or have the rate controlled by a midi note etc etc etc.
There would be also memory components like Add, Mult, Concatenate, Section, Record etc. A module with a wave could than be easily created and dragged to the toolbox. Two waves could be combined by extracting a Section from each and concatenating etc. I think even a front panel could be created for basic wave editing.
I think the possibilities after exposing the memory through connectors are endless. I'd probably leave the finding of those possibilities to the users and just concentrate on providing flexible tools. Creating a wave file component with a memPointer output is easy, just a question of removing some of the code from the existing one. Exposing memory pointers through connectors is also easy in terms of code, so some kind of sample support might happen sooner than you think.
lalo ·
DFD ..direct from disk for big samples..with a little amount being loaded in RAM and the rest read from HD...
with the RAM/DFD ratio being set by the user..
...almost like NI Kontakt...
yeah jorge!
exposing arrays' pointer is the way to go i guess 🙂
another idea (as i said) is to share array between different code components and schematic's portion so it will be possible to deal with the same array in different ways 🙂
lalo
Nu Audio Science ·
Jorge i'm a sample freak so do your worst 🙂
I can't honestly say i never understood a word of what you typed but i will obviously investigate when its all available 🙂
For me personally its romplers and beat choppers all the way.
Shifrin ·
Wow jorge, what a great idea - and as you said not too taxing to implement! I am constantly amazed by SM and by you guys (malc/jorge), and for that matter the rest of the guys here 🙂
Shif.
stefan ·
jorge wrote:
Shifrin wrote: It's a very interesting idea guys, you seem to have covered most bases with the various suggestions! Would be interesting to see what malc/jorge think about this? Although I do realise it could be quite some time before something like this happens!
I was thinking about this earlier. I think a lot will be possible just by exposing array ( or memory pointer which is the same thing ) as connectors going in and out of the code component. The existing wave file component would be changed to just output a pointer to the wave memory. The code component could then be used to create a very flexible wave player that could play the wave once and stop, or loop, it could play 1 sample per sample, or 1.5 sample per sample, or count up and down, or have the rate controlled by a midi note etc etc etc.
There would be also memory components like Add, Mult, Concatenate, Section, Record etc. A module with a wave could than be easily created and dragged to the toolbox. Two waves could be combined by extracting a Section from each and concatenating etc. I think even a front panel could be created for basic wave editing.
I think the possibilities after exposing the memory through connectors are endless. I'd probably leave the finding of those possibilities to the users and just concentrate on providing flexible tools. Creating a wave file component with a memPointer output is easy, just a question of removing some of the code from the existing one. Exposing memory pointers through connectors is also easy in terms of code, so some kind of sample support might happen sooner than you think.
Also, add a "read ahead from disk" integer input to the wave player and maybe a "stream from disk" boolean input (or use 0 bytes read ahead to turn streaming off). 🙂
Nu Audio Science ·
I dunno what your all talkin about but does it end up with me being able to do zones and so on ?
Ifso niiiiice 🙂
jorge ·
Nu Audio Science wrote: I dunno what your all talkin about but does it end up with me being able to do zones and so on ?
Ifso niiiiice 🙂
🙂 Now I dont know what you're talking about. Luckily I think there's plenty of people here that can translate between sampling and coding vocabulary.
stefan ·
Nu Audio Science wrote: I dunno what your all talkin about but does it end up with me being able to do zones and so on ?
Ifso niiiiice 🙂
Zones will be done with basic SM functionality, not specific to sample playing at all 🙂
Nu Audio Science ·
When im talking zones im talking about ala soundets, All built into one file, Then folders with lots of those files in to make presets out of, Well a rompler 🙂
I already noticed that Jorge mentioned some basic wav editing so my hopes are up for a beat chopper.
This is the sort of stuff that will get me learning SM properly 🙂
lalo ·
key zones and velocity zones can be don with midi components like filters and transformers...
i don't know how to do crossfade zones now...
but i guess is a matter of conditional statements about midi data..
i.e if a note is above A1 then A#1 will have 3 velocity points less , B will get 6 points less....
and all the curves possible..
for jorge
Sampling keyzones are range of note-numbers and velocity values withn you have a particular sample playing
for example
from A1 to C2 (with velocity from 0 to 63) =soft piano sample
from A1 to C2 (with velocity from 63 to 127) =hard piano sample
from C#2 to B4 (vel 0-63) = my dog cryin'
from C#2 to B4 (vel 64-90) = my dog screaming
from C#2 to B4 (vel 91-127) = my dog farting 😀
and so on
crossfading can overlap the zones following fading curves
so you can have kind of 'twilight' zones when passing from a note number/velocity zone to another
lalo
lalo ·
Nu Audio Science wrote: When im talking zones im talking about ala soundets, All built into one file, Then folders with lots of those files in to make presets out of, Well a rompler 🙂
I already noticed that Jorge mentioned some basic wav editing so my hopes are up for a beat chopper.
This is the sort of stuff that will get me learning SM properly 🙂
beat chopping will be possible i guess with a kind or peak detector/ enevelope follower (wich is already doable with code component)
plus we have arrays so the logic can be
where a peak is found (wich lasts at least some sample..another use for arrays) a flag is set wich points to the array position where the peak starts...
then a midi note will be assigned to that array point...
does it make any sense?
lalo
unkargherth ·
stefancrs wrote:
Zones will be done with basic SM functionality, not specific to sample playing at all 🙂
In fact i started some (unfinished) work on this. it's a keytracker based on midi note, emulating the DX7 tracking. With a bit of wisdom could be converted into a keyboard controlled layer mixer, that's is, basically a not so trivial keyboard zone system.
And, I agree on stefan, zone/layer should be llimited to samples. Complex synths (like nildon) and/or effects ( imagine diferent delays triggered by keyboard note) could benefit from this
Nu Audio Science ·
I was thinking beat chopping more along the lines of visually, Like acids beat chopper or tauregs variator, Selector start and end points visually on the waveform and then pick em up and move it to wherever you like 🙂
This of course would eventually get hooked up to some kind of sequencer allowing painting of blocks ala acid and so on inside a plug 🙂
I know im wafflin 🙂 🙂
Tom7777 ·
I think modules would be cool with these type of things, a lot of stuff can be made with code but a lot of people cannot code. 🙂
stefan ·
unkargherth wrote:
stefancrs wrote:
Zones will be done with basic SM functionality, not specific to sample playing at all 🙂
In fact i started some (unfinished) work on this. it's a keytracker based on midi note, emulating the DX7 tracking. With a bit of wisdom could be converted into a keyboard controlled layer mixer, that's is, basically a not so trivial keyboard zone system.
And, I agree on stefan, zone/layer should be llimited to samples. Complex synths (like nildon) and/or effects ( imagine diferent delays triggered by keyboard note) could benefit from this
You mean "shouldn't", right? 🙂
unkargherth ·
stefancrs wrote:
unkargherth wrote:
And, I agree on stefan, zone/layer shouldn't be limited to samples. Complex synths (like nildon) and/or effects ( imagine diferent delays triggered by keyboard note) could benefit from this
You mean "shouldn't", right? 🙂
Yes, of course
Tom7777 ·
There seems to be bugs when working with huge structures with wires not connecting and modules not deleting ect, i think this will be fixed hopefully, certain sampling things will definately not be possible until this is fixed basically.
TheAudiophileDutchman ·
As the release of SM v1.0 is getting closer and closer, I would like to bring this 'really old' thread back into the spotlights. 😇
And also this one:
[old link]
Many of the interesting remarks and features on the use of samples have been covered here and so far some have been implemented in SM 😉
> QUESTION: what sample functionality should/will make it already in SM v1.0? 😮
For instance, I would think native 24bit support and a(ny) kind of DFD is essential, because they're difficult/nearly impossible to do otherwise.. 😍
jorge ·
Arjan Schuurman wrote: For instance, I would think native 24bit support and a(ny) kind of DFD is essential
The wave file component only loads 16 bit wave files at the moment but it's very easy to add support for other formats including 24bit. Just keep bumping if it's taking too long, I dont think it will.
Once a wave file is loaded inside the wave file component, the data is converted to 32 bit floats which is the internal format used by SM. This means that SM in general already uses a higher precision format than 24 bits, no general changes are required.
Nu Audio Science ·
Beeeeeeehumpitydumpity
That being for some of the suggestions in this thread, In my particular case i need some kind of soundset (Something that holds all the keymapped samples) as a single file that loads into SM somehow, Using a bunch of these in a folder allowing you to move up and down through them as needed (Basically like any rompler)
Something familiar would be nice so that mapping the samples is easy, SF2 is supported well enough so maybe that would be the choice, I know comparisons to SE are annoying but it's SF2 oscilator really is great but has some really bad memory management issues making huge romplers in SE an impossibilty, The only reason i mention it is because it was me bugging Jeff that got the SF2 oscilator and he told me back then it would probably stay the same until V2.
Of the other modular packages out there it seems like an area that is seriously lacking so worth the effort i believe.
sonicfire ·
Nu Audio Science wrote: Beeeeeeehumpitydumpity
That being for some of the suggestions in this thread, In my particular case i need some kind of soundset (Something that holds all the keymapped samples) as a single file that loads into SM somehow, Using a bunch of these in a folder allowing you to move up and down through them as needed (Basically like any rompler)
Something familiar would be nice so that mapping the samples is easy, SF2 is supported well enough so maybe that would be the choice, I know comparisons to SE are annoying but it's SF2 oscilator really is great but has some really bad memory management issues making huge romplers in SE an impossibilty, The only reason i mention it is because it was me bugging Jeff that got the SF2 oscilator and he told me back then it would probably stay the same until V2.
Of the other modular packages out there it seems like an area that is seriously lacking so worth the effort i believe.
i second that 🙂 support for SF2 would be VERY nice IMHO 😀
infuzion ·
A bump for RP for Memory &/or Float array in/out of Code/ASM please.
Memory question!
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker