You’re adding features from the filter and AMP stages. I’m pretty sure he’s comparing sample ENGINES, i.e. before the filter, AMP, and FX stages…
I have no experience with the Rytm so I’m not saying it’s good or bad. But out of curiosity: how many different kinds of analog hihats are there anyway? What parameters would you like to add?
It’s not perfect. It’s pretty damn good and fairly unique, however.
Can you fine-tune the starting point of a sample on the Korg Volca?
[quote=“” KOTARE""]
You’re adding features from the filter and AMP stages. I’m pretty sure he’s comparing sample ENGINES, i.e. before the filter, AMP, and FX stages…
[/quote]
i’m confused now - how can you compare a volca sample to the AR then? volca has 0 engines… as in, no separate env stages etc. The only way to compare the two IMO is feature-by-feature, and to me it seems that AR can do everything the volca samp can…
I have two ryrms and zero complaints.
The rytm does so much you really need to schedule your time to its individual aspects. I spend a few hours just making a kit, set it down and do something else. Then when my creative energy charges back up I’ll take it out and make a few patterns. Stop again, tomorrow I’ll fine tune my reverb and delay parameters while adjusting panning accordingly and playing with microtiming.
Just because you can create a whole track from scratch all at once on elektron machines doesn’t mean you should. Its far too easy to get lost in all the options and you can get burnt out fast if you have high expectations with little actual experience.
I just got a nice console to run the individual outs through and that completed the rytm experience for me. I would highly suggest it to anyone else having trouble dealing with the many amplitude options as it makes balancing the drums so much easier.
- Biggest reality check to consider *
As the ryrm drum synthesis is based on the 909/808 its silly to think it doesn’t require the same outboard processing as its forerunners to sound up to snuff.
i’m confused now - how can you compare a volca sample to the AR then? volca has 0 engines… as in, no separate env stages etc. The only way to compare the two IMO is feature-by-feature, and to me it seems that AR can do everything the volca samp can…[/quote]
You COULD compare the two like that, but I got the impression he was talking about options to digitally effect the sample playback itself before filter and AMP stages, in which case it’d be a fair comparison.
Otherwise, you’re right, the RYTM smashes it in its total capacity, but then again there’s a $1000+ difference between the two…
[quote=“” Geneoart""]
[quote=“virtual_flannel”][quote=“mkdsl”]How about sample offset from the analog part?
So one of the parts can be used as the transient and the other for the body… Or swing values less than 50%, to have that early swing typical of samba rhythms?
There is always room for improvement
[/quote]
Ive always thought that would be dope for layering snares and claps. that little bit of space between the samples is what makes layering so powerful.[/quote]
Why couldn’t you just bake that offset in your sample before loading the sample?[/quote]
Because I have thousands of samples and don’t want to manually add air to them all.
this and the terrible inaccuracy of samp start param with longer samplechains. some kind of trig delay parameter would be great, either to the samp layer or both. Also, this would be a great target for LFO modulation for adding “humanize/drunk” to patterns
Well I love my RYTM but of course there could be improvements such as:
[ul]
[li]More machines with more synthesis options per machine.[/li]
[li]More freely assignable LFOs and envelopes.[/li]
[li]More types of digital FX[/li]
[li]More options for pad assignments in perf mode (mixed perf and snapshots would be cool)[/li]
[li]Quicker sample loading & more sample slots per project.[/li]
[li]More options for 2x time tempo and 0.5 time tempo per track. Id like to be able to emulate 8 and 16 bar tracks for longer seeming sequences in single patterns.[/li]
[/ul]
Im sure we will see some of these and others maybe not, but either way Im already loving my RYTM its the best box Elektron produce already IMHO.
I have the AR and the OT. I still don’t understand, why it’s so horrible to load samples in the AR ? In the OT they made it so easy. Just drag and drop. Why they didn’t make it like that in the AR (who is 4 years younger) ? Can anyone explain ?
Thanx
tm
What kind of problems do you get with timing using sample chains? I haven’t noticed this. Maybe I’m drunk.
what I mean was, at the current implementation, if you have a sample chain with more than a few slices on it, it’s almost impossible to add “leading silence” to a sample sound trig… and you cannot really add the silence to every slice since you cannot “offset” it away at the param level for sample slices that you’d want to trig from the start of the sound…
You can do that with a LFO–>sample start. LFO trig on. Finer control on Sample page. I think LFO depth is pretty high resolution. You might be able to do something with velocity—>sample start too.
The pads are stiff tho, I’ve had my AR since release and they’re still stiff as fuk. The Maschine’s pads are better and easier to play on. I feel like the Rytm can’t pick up all of my hits if I play fast, it’s definitely not suitable for finger drumming.
I might be able to shine some light on this.
What differs between the RYTM and OT is how the USB port is configured. I don’t own an OT but I can safely assume that since dragging and dropping are supported - the USB on the OT is configured as a mass storage device. The RYTM on the other hand has the USB configured as an audio interface, hence how Overbridge can multi-out via USB. Since mass storage functionality isn’t built into the RYTM, you need to upload via different means, hence why C6 is needed.
The sensible solution, if possible, would be for Elektron to update the firmware on the RYTM and enable a Global menu option which changes the USB behavior from Audio Interface to Mass Storage Device and route the USB directly to the +Drive so you can treat it as though it were a 1GB USB drive. If they were to make this possible, it would literally obliterate the Achilles heel on what is an otherwise fantastic drum machine.
Wishful thinking though.
I might be able to shine some light on this.
What differs between the RYTM and OT is how the USB port is configured. I don’t own an OT but I can safely assume that since dragging and dropping are supported - the USB on the OT is configured as a mass storage device. The RYTM on the other hand has the USB configured as an audio interface, hence how Overbridge can multi-out via USB. Since mass storage functionality isn’t built into the RYTM, you need to upload via different means, hence why C6 is needed.
The sensible solution, if possible, would be for Elektron to update the firmware on the RYTM and enable a Global menu option which changes the USB behavior from Audio Interface to Mass Storage Device and route the USB directly to the +Drive so you can treat it as though it were a 1GB USB drive. If they were to make this possible, it would literally obliterate the Achilles heel on what is an otherwise fantastic drum machine.
Wishful thinking though.
[/quote]
That exact feature is on the Zoom R16.
Which is both brilliant and sad considering what the price difference is. This feature is something I would expect in a $1400 drum machine, and really it would be in Elektrons best interest to implement it - god knows how many complaints I’ve already come across and how many trouble tickets they’ve probably received centric around this issue.
Why they didn’t do this to begin with is beyond me.
I’d also like drag’n’drop functionality and it sounds like we’ll get easier file management via Overbridge at some point.
But…c’mon, C6 and the file structure on the RYTM isn’t exactly difficult, just not quite as convenient as it could be.
Also, remember that the RYTM converts all the files it’s importing to 48khz so it’s bound to take longer than a normal transfer and I guess this also means that standard mass storage device USB behaviour wouldn’t work so that’s why it’s not implemented and they’re working on their own solution.
C6 is slow, crashes on large batch file transfers often, and slows down production processes.
I think these are good enough reasons to improve it