I think I've found a huge KONG bug in Reason 10.3

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
Post Reply
Soufyen
Posts: 6
Joined: 23 Jun 2017

16 Apr 2019

Since I've updated, I opened a song that suddenly sounded completely off. I managed to track down the potential bug to KONG.

Basically, if I connect pad 1 via CV output to pad 2 and pad 2 to pad 3, and then play pad 1, the sound will have a considerable lag. If I play pad 2, the lag is shorter. Only until I actually play pad 3, does the sound match up to the tempo. I've tried recreating the same problem with Redrum, but there it plays correctly, so I think this is specifically a KONG bug. It's difficult to explain so please check the file out for a detailed look and let me know if you have the same problem.

If this is really a bug (I'm almost certain), then this will mess up hundreds of my songs. I'm surprised it slipped through as it is a very obvious one. Surely I'm not the only one who uses CV this way?

https://www.dropbox.com/s/vtr0yxz63jgxq ... eason?dl=0

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

16 Apr 2019

It's not a bug. With the new update, CV is now affected by latency. If you set your buffer to 64 samples it'll work as it did before.

That said, instead of using CV you can actually link the pads within Kong itself (no cables). This way it won't be affected by latency.


User avatar
dioxide
Posts: 1780
Joined: 15 Jul 2015

16 Apr 2019

What I don't understand is why this affects Kong, but not Redrum. You can chain Redrum drums both in the device and between several devices and you won't get the type of delay you see when you try this with Kong. Does anyone know what makes Kong different in this respect?

User avatar
dioxide
Posts: 1780
Joined: 15 Jul 2015

16 Apr 2019

QVprod wrote:
16 Apr 2019
...you can actually link the pads within Kong itself (no cables). This way it won't be affected by latency.
There are only 3 Link slots though, so it depends on how much of this kind of layering you do. If it is more than 3 per song, you're out of luck. As QVprod says, you may have to work with a 64 sample buffer.

User avatar
dioxide
Posts: 1780
Joined: 15 Jul 2015

16 Apr 2019

dioxide wrote:
16 Apr 2019
What I don't understand is why this affects Kong, but not Redrum. You can chain Redrum drums both in the device and between several devices and you won't get the type of delay you see when you try this with Kong. Does anyone know what makes Kong different in this respect?
I just tried with some of Quadelectra's Jackboxes. It is the same as Kong, with a CV delay. I wonder if Kong is built in a similar way to a RE? Umph also acts like Kong does.

User avatar
chimp_spanner
Posts: 2908
Joined: 06 Mar 2015

16 Apr 2019

Yeah it’s all in the release notes. This is what they refer to as a feedback loop (connecting a device to itself). In the case of Kong, you’d be better off using pad groups or flattening layered sounds down to wave. If you need the old behaviour just disable the audio interface buffer setting or run at 64. It’ll still probably run better than it did before.

Crucially you can trigger more than one pad from a single split CV source (so long as that source is separate from the device you’re triggering) without any delay, at any buffer size.

But yeah, as far as this post goes; in truth it was never instant - it was just locked at 64 samples. If you turn off the new setting and connect all the Kong pads together in series and trigger the same sample on all of them, the result isn’t just louder. It’s kinda flanged.

So for most people it’ll probably be a per project thing. Mattias explained the changes made to CV pretty well so I’d recommend reading through that and then experimenting with different connections so you know what’s going on and what you’re doing.

User avatar
kuhliloach
Posts: 880
Joined: 09 Dec 2015

16 Apr 2019

Image

User avatar
MattiasHG
Reason Studios
Posts: 488
Joined: 16 Jan 2015

17 Apr 2019

dioxide wrote:
16 Apr 2019
What I don't understand is why this affects Kong, but not Redrum. You can chain Redrum drums both in the device and between several devices and you won't get the type of delay you see when you try this with Kong. Does anyone know what makes Kong different in this respect?
It's a complicated and kind of funny thing. Try connecting a gate out from Redrum channel 3 to Redrum channel 1. Voila, delay!

Redrum's really old and is rendered in a peculiar way, rendering each channel in order. Therefore, channel 1 is actually rendered before channel 3 so channel 3 can "know" there's a gate coming in. If you do it backwards though, channel 1 won't know there's a gate coming from channel 3 until after it's been render—i.e. the next buffer, resulting in a delay. This was also true before, but the delay was only 64 samples so you probably didn't notice it. Now it's as big as your buffer so for a shorter delay, use a shorter buffer.

I've talked a bit about this previously, but this is part of why we originally designed Reason to only use 64 sample buffers internally. To allow for free routing with as little audible impact as possible. But since the introduction of VST clearly showed that users were expecting better performance, performance that in reality depended on us not forcing a set buffer size, that's now changed. You can still go back to how it was in the Audio preferences or simply use a very low buffer size (like 64 or 128) and you won't notice the delays. :geek:

User avatar
dioxide
Posts: 1780
Joined: 15 Jul 2015

17 Apr 2019

MattiasHG wrote:
17 Apr 2019
dioxide wrote:
16 Apr 2019
What I don't understand is why this affects Kong, but not Redrum. You can chain Redrum drums both in the device and between several devices and you won't get the type of delay you see when you try this with Kong. Does anyone know what makes Kong different in this respect?
It's a complicated and kind of funny thing. Try connecting a gate out from Redrum channel 3 to Redrum channel 1. Voila, delay!

Redrum's really old and is rendered in a peculiar way, rendering each channel in order. Therefore, channel 1 is actually rendered before channel 3 so channel 3 can "know" there's a gate coming in. If you do it backwards though, channel 1 won't know there's a gate coming from channel 3 until after it's been render—i.e. the next buffer, resulting in a delay. This was also true before, but the delay was only 64 samples so you probably didn't notice it. Now it's as big as your buffer so for a shorter delay, use a shorter buffer.

I've talked a bit about this previously, but this is part of why we originally designed Reason to only use 64 sample buffers internally. To allow for free routing with as little audible impact as possible. But since the introduction of VST clearly showed that users were expecting better performance, performance that in reality depended on us not forcing a set buffer size, that's now changed. You can still go back to how it was in the Audio preferences or simply use a very low buffer size (like 64 or 128) and you won't notice the delays. :geek:
Thanks for the explanation. That explains why Redrum is different. I use Redrum's Gates to trigger my other drum devices, so I'm keen to learn how the changes affect timing. Until there is a Redrum-like device as a Player, I have to use CV for this instead of MIDI. Even then I think CV is better for me as currently I have my drums individually as Combinators trigger by a Gate input.

I noticed that the Buffer settings are also used for rendering audio. On the one hand this means that the export will sound exactly the same as the live version, but it also means that there could be timing issues with an export, or that a Reason Song might sound different exported from two different installations of Reason, or even if you just change the buffer at some point. People are going to have to be careful with this, so I think it needs to be talked about so people understand the pitfalls. I don't use VSTs so theoretically I can use 64 samples for studio work, but I often bump up the buffer when I play live, as not having audio crackles is very important. I'm going to have to be careful with this I think.

antic604

17 Apr 2019

dioxide wrote:
17 Apr 2019
...Until there is a Redrum-like device as a Player, I have to use CV for this instead of MIDI...
How is Redrum better - as a sequencer - than Drum Sequencer?

User avatar
chimp_spanner
Posts: 2908
Joined: 06 Mar 2015

17 Apr 2019

antic604 wrote:
17 Apr 2019
dioxide wrote:
17 Apr 2019
...Until there is a Redrum-like device as a Player, I have to use CV for this instead of MIDI...
How is Redrum better - as a sequencer - than Drum Sequencer?
Well, more steps I guess? Up to 64? I can see how that’d be useful to some, although in reality editing 64 steps is no different to editing 4x16 patterns in DrumSeq as they’re all on different pages. And I prefer the overview I get from DrumSeq also. But I can see how people might like to work in ReDrum!

User avatar
motuscott
Posts: 3420
Joined: 16 Jan 2015
Location: Contest Weiner

17 Apr 2019

I love listening to people who understand Reason explain how it works.
It's like talking to a dog about geometry
"eyes squint, head tilts"
Who’s using the royal plural now baby? 🧂

User avatar
dioxide
Posts: 1780
Joined: 15 Jul 2015

17 Apr 2019

antic604 wrote:
17 Apr 2019
dioxide wrote:
17 Apr 2019
...Until there is a Redrum-like device as a Player, I have to use CV for this instead of MIDI...
How is Redrum better - as a sequencer - than Drum Sequencer?
In many, many ways:

1. It has 10 drum slots, not 8.
2. It handles pattern changes in a better way, waiting until the end of the bar until changing the pattern, like a drum machine should.
3. It has three set velocity levels, which can be input using modifier keys.
4. It has 64 patterns instead of 8.
5. The Pattern Lane automation shows the pattern length.
6. Redrum has features that DS does not, including Flam control, Global resolution control, Global pattern length
7. DS's Remote implementation is woefully under-specced. Redrum allows full programming via Remote, DS doesn't offer any.
8. DS has very limited automation options. Some of Redrum's features can be recreated up to a point in DS, but not automated.
9. You can copy and paste pattern in Redrum using key commands - to be honest I'm not even sure if it possible to copy and paste patterns in DS?
10. Up to 64 step patterns.

So there you have it. Drum Sequencer is a simple device, way too simple for anyone who is an experienced Redrum user. Propellerhead more or less got Redrum right in version 1 of Reason. It's a device that emulates drum machines of the 80s and 90s that were designed for musicians. Drum Sequencer is closer to a Eurorack module, designed to do outlandish things. Some of the functionality is cool but it isn't a patch on Redrum.

User avatar
MattiasHG
Reason Studios
Posts: 488
Joined: 16 Jan 2015

17 Apr 2019

dioxide wrote:
17 Apr 2019
MattiasHG wrote:
17 Apr 2019


It's a complicated and kind of funny thing. Try connecting a gate out from Redrum channel 3 to Redrum channel 1. Voila, delay!

Redrum's really old and is rendered in a peculiar way, rendering each channel in order. Therefore, channel 1 is actually rendered before channel 3 so channel 3 can "know" there's a gate coming in. If you do it backwards though, channel 1 won't know there's a gate coming from channel 3 until after it's been render—i.e. the next buffer, resulting in a delay. This was also true before, but the delay was only 64 samples so you probably didn't notice it. Now it's as big as your buffer so for a shorter delay, use a shorter buffer.

I've talked a bit about this previously, but this is part of why we originally designed Reason to only use 64 sample buffers internally. To allow for free routing with as little audible impact as possible. But since the introduction of VST clearly showed that users were expecting better performance, performance that in reality depended on us not forcing a set buffer size, that's now changed. You can still go back to how it was in the Audio preferences or simply use a very low buffer size (like 64 or 128) and you won't notice the delays. :geek:
Thanks for the explanation. That explains why Redrum is different. I use Redrum's Gates to trigger my other drum devices, so I'm keen to learn how the changes affect timing. Until there is a Redrum-like device as a Player, I have to use CV for this instead of MIDI. Even then I think CV is better for me as currently I have my drums individually as Combinators trigger by a Gate input.

I noticed that the Buffer settings are also used for rendering audio. On the one hand this means that the export will sound exactly the same as the live version, but it also means that there could be timing issues with an export, or that a Reason Song might sound different exported from two different installations of Reason, or even if you just change the buffer at some point. People are going to have to be careful with this, so I think it needs to be talked about so people understand the pitfalls. I don't use VSTs so theoretically I can use 64 samples for studio work, but I often bump up the buffer when I play live, as not having audio crackles is very important. I'm going to have to be careful with this I think.
To be clear: nothing's changed if you just send gates from Redrum to another device in the rack. Those are not affected by buffer size, they're in series and can be rendered normally. The buffer size only affects things if you:
  • Create a feedback loop (CV or audio)
  • Send CV signals other than Note/Gate to a VST
  • Automate a VST parameter

User avatar
dioxide
Posts: 1780
Joined: 15 Jul 2015

17 Apr 2019

So does the buffer only affects VST automation? REs and Stock devices aren't affected?

User avatar
MattiasHG
Reason Studios
Posts: 488
Joined: 16 Jan 2015

17 Apr 2019

dioxide wrote:
17 Apr 2019
So does the buffer only affects VST automation? REs and Stock devices aren't affected?
Correct, in regards to automation. REs and built-in devices work just as before. I tried to be as clear as I could here: https://www.propellerheads.com/blog/reason-103-is-here :)

But again, this is music so in my opinion: if you can't hear an issue, it's not an issue.

User avatar
ScuzzyEye
Moderator
Posts: 1402
Joined: 15 Jan 2015
Contact:

17 Apr 2019

dioxide wrote:
17 Apr 2019
Thanks for the explanation. That explains why Redrum is different. I use Redrum's Gates to trigger my other drum devices, so I'm keen to learn how the changes affect timing. Until there is a Redrum-like device as a Player, I have to use CV for this instead of MIDI. Even then I think CV is better for me as currently I have my drums individually as Combinators trigger by a Gate input.

I noticed that the Buffer settings are also used for rendering audio. On the one hand this means that the export will sound exactly the same as the live version, but it also means that there could be timing issues with an export, or that a Reason Song might sound different exported from two different installations of Reason, or even if you just change the buffer at some point. People are going to have to be careful with this, so I think it needs to be talked about so people understand the pitfalls. I don't use VSTs so theoretically I can use 64 samples for studio work, but I often bump up the buffer when I play live, as not having audio crackles is very important. I'm going to have to be careful with this I think.
If you use one Kong to trigger other Kongs (possibly with CV splitter(s) in between) this won't be an issue. It's only when a Kong is triggering itself.

Export and live playback are both considered "rendering" by the checkbox. If you uncheck it, you'll get the 10.2 signal flow. 64-samples per CV event, but larger buffers for rendering audio into. If you don't use VSTs, and the 10.2 performance was good enough, that might be an option for you.

JerrelTheKing
Posts: 226
Joined: 31 Aug 2015

19 Apr 2019

dioxide wrote:
17 Apr 2019
antic604 wrote:
17 Apr 2019


How is Redrum better - as a sequencer - than Drum Sequencer?
In many, many ways:

1. It has 10 drum slots, not 8.
2. It handles pattern changes in a better way, waiting until the end of the bar until changing the pattern, like a drum machine should.
3. It has three set velocity levels, which can be input using modifier keys.
4. It has 64 patterns instead of 8.
5. The Pattern Lane automation shows the pattern length.
6. Redrum has features that DS does not, including Flam control, Global resolution control, Global pattern length
7. DS's Remote implementation is woefully under-specced. Redrum allows full programming via Remote, DS doesn't offer any.
8. DS has very limited automation options. Some of Redrum's features can be recreated up to a point in DS, but not automated.
9. You can copy and paste pattern in Redrum using key commands - to be honest I'm not even sure if it possible to copy and paste patterns in DS?
10. Up to 64 step patterns.

So there you have it. Drum Sequencer is a simple device, way too simple for anyone who is an experienced Redrum user. Propellerhead more or less got Redrum right in version 1 of Reason. It's a device that emulates drum machines of the 80s and 90s that were designed for musicians. Drum Sequencer is closer to a Eurorack module, designed to do outlandish things. Some of the functionality is cool but it isn't a patch on Redrum.
All absolutely correct. I was really excited about DS when it first came out but all these examples brought me right back to ReDrum in a days time..

User avatar
sonicbyte
Posts: 347
Joined: 16 Jan 2015
Location: Argentina
Contact:

19 Apr 2019

Yeah I hate that DS doesn't wait to switch from one pattern to another like redrum does.

User avatar
fullforce
Posts: 849
Joined: 18 Aug 2018

19 Apr 2019

MattiasHG wrote:
17 Apr 2019
I've talked a bit about this previously, but this is part of why we originally designed Reason to only use 64 sample buffers internally. To allow for free routing with as little audible impact as possible. But since the introduction of VST clearly showed that users were expecting better performance, performance that in reality depended on us not forcing a set buffer size, that's now changed. You can still go back to how it was in the Audio preferences or simply use a very low buffer size (like 64 or 128) and you won't notice the delays. :geek:
Compliments Mattias. You sound like a real product manager here! And that is not sarcastic. :)
This is a block of text that can be added to posts you make. There is a 255 character limit.

reggie1979
Posts: 1181
Joined: 11 Apr 2019

19 Apr 2019

I'm confused. It sounds as if it's "we improved xyz but that left abc not as usable as before".

And what about this buffer stuff? I run my soundcard at 64 buffer. What does it mean internal buffer 64-128, same as a soundcard buffer?

Musicians need to spend time making music, not being re-educated on teh maths! :lol:

User avatar
QVprod
Moderator
Posts: 3488
Joined: 15 Jan 2015
Contact:

20 Apr 2019

reggie1979 wrote:
19 Apr 2019
I'm confused. It sounds as if it's "we improved xyz but that left abc not as usable as before".

And what about this buffer stuff? I run my soundcard at 64 buffer. What does it mean internal buffer 64-128, same as a soundcard buffer?

Musicians need to spend time making music, not being re-educated on teh maths! :lol:
Don't think about it too hard. Running at 64 samples gives the same performance you're used to. CV feedback loops are just now affected by higher buffers which can optionally be turned off. Most people probably won't be affected though.

User avatar
mcatalao
Competition Winner
Posts: 1824
Joined: 17 Jan 2015

20 Apr 2019

Man... You guys are over complicating things.
Music is made of "delays". And delays even help you on a lot of stuff, like unmasking stuff on the beat and so on (have you ever delayed a bunch of claps because you couldn't hear them? It's a pretty neat trick that mimics what happens in real life when musicians play real instruments together - I'm not being patronizing, it's just real).

This CV and Automation issue, is only an issue if you have phasing problems. So, for old projects disable the Big Batch buffer if you notice anything sounding differently. If its a new project, forget the issue as it was never there.

tanni
Posts: 213
Joined: 19 Jul 2015

22 Apr 2019

dioxide wrote:
17 Apr 2019
antic604 wrote:
17 Apr 2019


How is Redrum better - as a sequencer - than Drum Sequencer?
In many, many ways:

1. It has 10 drum slots, not 8.
2. It handles pattern changes in a better way, waiting until the end of the bar until changing the pattern, like a drum machine should.
3. It has three set velocity levels, which can be input using modifier keys.
4. It has 64 patterns instead of 8.
5. The Pattern Lane automation shows the pattern length.
6. Redrum has features that DS does not, including Flam control, Global resolution control, Global pattern length
7. DS's Remote implementation is woefully under-specced. Redrum allows full programming via Remote, DS doesn't offer any.
8. DS has very limited automation options. Some of Redrum's features can be recreated up to a point in DS, but not automated.
9. You can copy and paste pattern in Redrum using key commands - to be honest I'm not even sure if it possible to copy and paste patterns in DS?
10. Up to 64 step patterns.

So there you have it. Drum Sequencer is a simple device, way too simple for anyone who is an experienced Redrum user. Propellerhead more or less got Redrum right in version 1 of Reason. It's a device that emulates drum machines of the 80s and 90s that were designed for musicians. Drum Sequencer is closer to a Eurorack module, designed to do outlandish things. Some of the functionality is cool but it isn't a patch on Redrum.
full agreement from my side !
The biggest mistake in Drum-Sequencer for me is: you cant switch the 8 patterns with Remote control directly. You have to switch the pattern one after another in circle, only up or downwards back-to-back ! Who had this invented ???? This is complete nonsense and idiodic for live-performances !!

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 27 guests