Sad that this actually needs to be a feature request. I thought modulating basic stuff was the whole point of the new modulation system, but here it goes:
It is apparently right now not possible to modulate the attack (or release, or…) of a sample in the sampler, to map it, for instance, to the input velocity. This is useful for creating realistic sounding instruments (i.e. sampled implementations of real, acoustic instruments).
I can only again encourage taktik and crew to have a look at basic hardware samplers, as available since 25 years, in order to get an idea what the basic functionality of a sampler is.
You can assign a macro to attack length (or whatever modulation parameter you want), and on the track dsp’s use velocity tracker + instr macro to modulate it with input velocity. Sure it would be more convenient to be able to do all this within the modulation system only but I wouldn’t say it’s impossible.
Yeah, or you can get over yourself and use basic common sense in order to achieve what you want in 2 steps as stated by Carbonthief. So yeah, it’s possible. Maybe not probable for you, but it’s definitely possible.
Or you can meander on over here and see that the crew explained all this in the manual.
That’s a hack, not a proper solution. Doesn’t work with a drum set with more than 8 drum sounds.
Btw, nice attitude to tell people to get over themselves when they just request a new feature…
This works for monophonic sounds only, because a keytracker triggering a macro always affects the attack of ALL played samples of the instrument/modulation set. All macro operations are applied globally to the instrument/modulation set. So if you’re playing polyphonic, each triggering of the keytracker affects also the attack of the currently/former played keys, not to talk about parallel hit keys not being able to be played with different velocities triggering the attack.
Agreed, using basic common sense often and for many would be a good thing.
This way low-skill people unite more low-skillers behind their back. That of course doesn’t make them more skilled. But it makes them feel stronger, when getting some “likes” from the same sort, for having you as “enemy” in common. Actually poor people, but you better get used to it, when you keep on criticizing Renoise. As I said in some other thread, criticizing Renoise you’re always the asshole. No matter if your point is valid or not.
Nobody here is directly an asshole. But even if nobody is one, we still like to point one out and call him one
But all crap aside, there most likely be a lot of valid points that the devs are very much aware of but not worked out.
It would be a much better help if they can respond with at least a hint that some of this stuff was not implemented intentionally but at least is planned/considered for implementation.
Imo the real thing would be to let people discuss solutions for issues and lacks, one at a time, that are later on really implemented then, with the devs moderating and if necessary intervening and explaining when and why the core definitively prevents some of these things. That’d be a useful, constructive dialog for all participants and might lead to way better results than the former way of development.
You’re ad-hoc’ing your original post. You stated simply that it was not possible to modulate the ASDR of a sample with no other stipulations, and you were proven wrong. />
I’m not a dev and I have no idea how hard it is to program within the current system, but I don’t think that passive-aggressively attacking the devs for not having ‘x’ feature in a modern tracker software is the best way to go about getting what you want, especially when you weren’t specific enough about what you wanted and why in the first place.
I didn’t attack anybody. I was criticizing a lack of a feature in a software product. Do you see the difference?
Oh and I made my unspecific request very specific by adding ‘in the sampler’ to the description now…
The suggestion by itself is all good, but the tone you present it with is a bit on the provocative side and that’s probably why someone reacts.
In a way you’re saying “you guys are so hopeless, it shouldn’t be necessary for me to tell you this…”, at least that is how many people will read it.
I’m not gonna shoot you for it and i like the idea. We’re all communicating in a way that is not developed in human beings, things can always be interpreted differently from the original intention. I’m certainly not an angel myself, even though i try to have it in mind i manage to give more crap than i want to.
INdeed using the lfo as an adsr is monophonic …explained it numerous times in numerous threads …
some People should learn to shut the fuck up , coming with half assed solutions when they don’t even know the difference between monophonic an polyphonic processing , and then telling someone to get over it .
Ohh yeah developers , please ad a curve setting to the decay stageof the adsr . thank you
btw …I am the asshole
Okay, so I’ve done some messing around, and I don’t know exactly what OP is planning on actually doing here or what his setup is, but here’s my next best solution. I don’t work with drum kits outside of 128s in Renoise, so this is something that I would never have the impulse to do.
If we’re applying this to a drum set, we’re not going to get more than 8 individual mappings of course. (Then again, that’s also assuming that you have more than 8 different drum sounds happening at the same exact time that can’t share modulation channels with similar sounds.)
In the new mod matrix, you can create different modulation sets, each with their own custom ASDR. I found out that you can assign the samples in your kit to a particular modulation set. You can then assign velocity trackers in different tracks in a group to an instrument macro in a group track where each macro would modulate each ASDR set, which would be assigned to whatever sample you choose on the left hand side of the sample window. The individual tracks would receive different information from the keyboard velocity which would feed into the mod matrix in the group track which would feed into the different modulation sets in the sampler which would modulate the ASDR of the samples in each individual set.
But what I’m guessing the problem actually is that many people are getting at is that the Renoise sampler functions like a tracker sampler, not like the Reason Kong or something similar like whatever Cubase natively uses. I don’t think it was ever meant to hold many independently modulated samples all within one instrument, especially when it’s so easy just to create a new instrument for each drum sample by itself. I guess what we’d like to see is having each designated keyzone have its own modulation matrix so for example I could sample an instrument many times so each note and sound would have its own key with its own system of self-contained modulation. That way it could function like an APC40 inside Ableton so you can mix out those mad dubstep tunes live.
I guess the reason for the 8-knob-solution were paragons like NI Massive or Synthmaster, where those knobs are used as quick access for the most important params of a sound. The difference is just, for those instruments still all parameters, quick knob or not, can be accessed via instrument automation, while for XRNIs the macro knobs are the absolute only way to access your parameters. So yes, unlimited macros would be important and in practice the limited number of macros doesn’t make any sense at all. It seems the only reason is “Let’s do it like all others”, without seeing the difference.
Personally i believe they thought 8 was plenty enough for a “simple” xrni, that they underestimated the trillion ways to use them. I didn’t even know i needed macros at all before 3.0, now i can’t get enough.
We’ll probably see more macros in the future, so we can only wait patiently and i’m shure it is possible to make some music with the 8 we have now in the meantime.
