I remember reading on this forum about an issue some users were having with Carve on some low end frequencies. I see that Ochen has updated this device, so I was wondering if those issues have been addressed and corrected?
I searched this forum and couldn't find the original thread, for some reason, so I am starting a new thread. Forgive me for not being able to locate the original thread.
Ochen K's update notes in the Prop Shop read: Update 1.0.2 Low frequency distortion bug fixed. So can I assume it's been resolved?
Ochen K Carve update. Did it fix low end issues?
Last edited by challism on 22 Jul 2015, edited 2 times in total.
As far as I know, it did fix the issue. Two people said they'd verify that it did before I submitted it to the shop so I sent them beta licenses. One person (jappe) reported that it did fix the issue. The other person (selig) never responded.
Challism and Theo, were you able to reproduce the issue before? If so, have either of you downloaded the latest version and tested it?
Challism and Theo, were you able to reproduce the issue before? If so, have either of you downloaded the latest version and tested it?
-
hydlide
Challism, I will guess that this is the thread you couldn't find?challism wrote:I searched this forum and couldn't find the original thread, for some reason, so I am starting a new thread. Forgive me for not being able to locate the original thread.
http://www.reasontalk.com/viewtopic.php?f=7&t=7480178
ochenk wrote:As far as I know, it did fix the issue. Two people said they'd verify that it did before I submitted it to the shop so I sent them beta licenses. One person (jappe) reported that it did fix the issue. The other person (selig) never responded.
Challism and Theo, were you able to reproduce the issue before? If so, have either of you downloaded the latest version and tested it?
sorry! I am such a doofus, I have 1.01 installed. I just noticed the 1.02. Please forgive my mistake.
I will update now and test right away. Hooray!
PS I also edited my first reply to say "AFAIK, yes", instead of "AFAIK, no".
Doh! Embarrassed to say I didn't follow up on this issue.ochenk wrote:As far as I know, it did fix the issue. Two people said they'd verify that it did before I submitted it to the shop so I sent them beta licenses. One person (jappe) reported that it did fix the issue. The other person (selig) never responded.
Challism and Theo, were you able to reproduce the issue before? If so, have either of you downloaded the latest version and tested it?
OK, a quick check of the frequency response shows something, but I want to double check when I have more time and fully address the issue so I don't mis-speak here. I'll test in a few different ways to make sure one test isn't giving false data.
Selig Audio, LLC
I haven't had a chance to try Carve since its release, so I was not able to reproduce it. I was also a beta tester, and couldn't produce the issue (didn't hear it) when it was in beta... none of us did, obviously. That's kind of embarrassing.
Anyway, this device is definitely on my want to buy list. You put out some really great products, Ochen. I found it very useful when I used it in beta. I'm glad you got the issue resolved.
That's kind of embarrassing. Anyway, this device is definitely on my want to buy list. You put out some really great products, Ochen. I found it very useful when I used it in beta. I'm glad you got the issue resolved.
OK, re-testing reveals the same issue I previously saw with Carve, that is to say it seems to have an issue responding to around 60 Hz and 110 Hz, which I'll demonstrate below. Additionally, as the frequency goes higher, the amount of ducking changes dramatically with it. If you duck a Pad with a bass note at 40 Hz (and at -12 dBFS) you'll get around 48 dB of ducking, but if that note plays an octave higher you'll get around 40 dB ducking. Continuing up two octaves will give you only 20 dB ducking! Once you get to 1 kHz and above you'll only get about 3-4 dB ducking. That may well be "by design", but it makes it difficult to get predictable results, as the amount of ducking can change dramatically with the frequencies being presented to the "Ref" input.
But the "bug" I have observed makes things even more un-predictable, and that is that the low frequency ducking amount varies widely up and down as you move up the scale. 40 Hz will give you 48 dB ducking with an input of -12 dBFS as previously stated, but 60 Hz gives you around 22 dB ducking. Continuing up, 80 Hz gives you 40 dB ducking while 100 Hz gives you around 28 dB ducking. It is best shown by this graph that shows the ducking amount at each frequency with equal level input ("ref") signals:
To clarify: The input signal was set to - 10 dBFS, and what I expected to see was a flat line some level below that. How far below that? There's no way of predicting that in this device, which is why there is no "Duck by X dB" control on the front panel. But even without having a clue how much ducking to expect, you would still expect equal ducking at all frequencies in order for it to be useful IMO. And beyond that, if it ISN'T equal at all frequencies you would at the very least expect a smoother curve without such huge peaks/dips. That's why I'm calling the uneven response I'm seeing here a "bug", because it's not likely that it was "by design".
But let's look just a little further, because there's another issue going on. If we look at a single frequency instead of a sweep, we see a different problem. Here is an example, which is the result of running a 60 Hz sine wave into the ref input (typical of a sub bass line) and measuring the resultant "ducking":
This shows ducking above and below 60 Hz, but what it SHOULD show is ducking ONLY at 60 Hz. So the issue isn't just that there is un-even ducking across the frequency spectrum but also that in some cases more than one frequency range is being ducked when only ONE should be ducked. As it stands, when ducking in response to a 60 Hz ref signal, the entire range from 30 to over 100 Hz is being ducked, some areas by 10-20 dB and some by up to 60 dB!
Finally, the frequency of the ducking, when it IS ducking a single frequency, isn't always accurate. Using a 30 Hz input you would expect to see ducking by some amount at 30 Hz. But instead you see ducking at around 43 Hz (half an octave higher than it should be):
I will conclude by stating that I was very careful when conducting these tests, but if anyone feels my methods are in question I will gladly change my testing procedures and re-test - I do not wish to mis-represent anyone's product in any way!
But the "bug" I have observed makes things even more un-predictable, and that is that the low frequency ducking amount varies widely up and down as you move up the scale. 40 Hz will give you 48 dB ducking with an input of -12 dBFS as previously stated, but 60 Hz gives you around 22 dB ducking. Continuing up, 80 Hz gives you 40 dB ducking while 100 Hz gives you around 28 dB ducking. It is best shown by this graph that shows the ducking amount at each frequency with equal level input ("ref") signals:
To clarify: The input signal was set to - 10 dBFS, and what I expected to see was a flat line some level below that. How far below that? There's no way of predicting that in this device, which is why there is no "Duck by X dB" control on the front panel. But even without having a clue how much ducking to expect, you would still expect equal ducking at all frequencies in order for it to be useful IMO. And beyond that, if it ISN'T equal at all frequencies you would at the very least expect a smoother curve without such huge peaks/dips. That's why I'm calling the uneven response I'm seeing here a "bug", because it's not likely that it was "by design".
But let's look just a little further, because there's another issue going on. If we look at a single frequency instead of a sweep, we see a different problem. Here is an example, which is the result of running a 60 Hz sine wave into the ref input (typical of a sub bass line) and measuring the resultant "ducking":
This shows ducking above and below 60 Hz, but what it SHOULD show is ducking ONLY at 60 Hz. So the issue isn't just that there is un-even ducking across the frequency spectrum but also that in some cases more than one frequency range is being ducked when only ONE should be ducked. As it stands, when ducking in response to a 60 Hz ref signal, the entire range from 30 to over 100 Hz is being ducked, some areas by 10-20 dB and some by up to 60 dB!
Finally, the frequency of the ducking, when it IS ducking a single frequency, isn't always accurate. Using a 30 Hz input you would expect to see ducking by some amount at 30 Hz. But instead you see ducking at around 43 Hz (half an octave higher than it should be):
I will conclude by stating that I was very careful when conducting these tests, but if anyone feels my methods are in question I will gladly change my testing procedures and re-test - I do not wish to mis-represent anyone's product in any way!
Selig Audio, LLC
I suspect the problems you see is related to when the fft frame size is not a multiple of the ref in sine wave period...then there would be overtones in the ref in analysis.
Though it seems like really heavy ones in your example in that case. Perhaps it is too short fft frame size for lower freq ref in content?
Also, some window function can be used to reduce the overtones?
Though it seems like really heavy ones in your example in that case. Perhaps it is too short fft frame size for lower freq ref in content?
Also, some window function can be used to reduce the overtones?
@Selig, this issue was replied by me from the beginning. not in detail but that you can hear unwanted harmonics & noises.
My endresult was it, not to buy this RE because a plugin that needs so much explanation isn´t good plugin for me. I like the idea behind this RE but it isn´t what I´ve had expected yet so far. For me as user is it important that the tool is working and annoying me, if I have always the feeling something isn´t right in a session when I´m using a tool like this, I´m kicking it out of my plugin list.
Make more music instead of wasting your time with a device like this
My endresult was it, not to buy this RE because a plugin that needs so much explanation isn´t good plugin for me. I like the idea behind this RE but it isn´t what I´ve had expected yet so far. For me as user is it important that the tool is working and annoying me, if I have always the feeling something isn´t right in a session when I´m using a tool like this, I´m kicking it out of my plugin list.
Make more music instead of wasting your time with a device like this
Hello Shokstar!Shokstar wrote:@Selig, this issue was replied by me from the beginning. not in detail but that you can hear unwanted harmonics & noises.
My endresult was it, not to buy this RE because a plugin that needs so much explanation isn´t good plugin for me. I like the idea behind this RE but it isn´t what I´ve had expected yet so far. For me as user is it important that the tool is working and annoying me, if I have always the feeling something isn´t right in a session when I´m using a tool like this, I´m kicking it out of my plugin list.
Make more music instead of wasting your time with a device like this
If your problems with Carve was the same as mine, then the latest patch solved it. Carve was clipping even if the Sig In signal wasn't clipping (and with zero Ref In signal). When ever the Sig In peaks were in the overhead area they were clipping, which they shouldn't. That's fixed now!
Curious about the issues Selig investigated though!
I guess a workaround until it's fixed could be to have equalizer(s) for the Ref In signal to even out the problems with inconsistent ducking for differenct frequencies.
That could actually be a feature request as well, to have an equalizer embedded in Carve ref in, so we can set priorities for which frequency regions we'd like Carve to emphasize and which to supress.
Hey, don't RE dev's use bug tracking tools btw!?
Would be nice if all (or most...) RE devs could agree on some bug tracking tool which we can use. Managing bugs through mail and forums must be hell.
Perhaps Prop's could set the standard and offer a common tool?
the Ref source was a sinewave sweep and what sound source was ducked by the sinewave sweep? A sinewave, white noise, a pad?selig wrote:
I think it was a sine Sig In- the same as used for Ref In; He used a sine in the investigation in this thread: http://reasontalk.com/viewtopic.php?f=7&t=7490649Shokstar wrote:the Ref source was a sinewave sweep and what sound source was ducked by the sinewave sweep? A sinewave, white noise, a pad?selig wrote:
EDIT: eh...my bad...it's obviously not the same sine in sig in as in ref in since he measures ducking of other frequencies than in ref in...
I guess it could still be a sine in sig in that he sweeps after changing the ref in sine frequency
An EQ cannot fix the example where there are two "dips" (one above and one below the Ref frequency) when the Ref input only contains one…jappe wrote:Hello Shokstar!Shokstar wrote:@Selig, this issue was replied by me from the beginning. not in detail but that you can hear unwanted harmonics & noises.
My endresult was it, not to buy this RE because a plugin that needs so much explanation isn´t good plugin for me. I like the idea behind this RE but it isn´t what I´ve had expected yet so far. For me as user is it important that the tool is working and annoying me, if I have always the feeling something isn´t right in a session when I´m using a tool like this, I´m kicking it out of my plugin list.
Make more music instead of wasting your time with a device like this
If your problems with Carve was the same as mine, then the latest patch solved it. Carve was clipping even if the Sig In signal wasn't clipping (and with zero Ref In signal). When ever the Sig In peaks were in the overhead area they were clipping, which they shouldn't. That's fixed now!
Curious about the issues Selig investigated though!
I guess a workaround until it's fixed could be to have equalizer(s) for the Ref In signal to even out the problems with inconsistent ducking for differenct frequencies.
That could actually be a feature request as well, to have an equalizer embedded in Carve ref in, so we can set priorities for which frequency regions we'd like Carve to emphasize and which to supress.
Hey, don't RE dev's use bug tracking tools btw!?
Would be nice if all (or most...) RE devs could agree on some bug tracking tool which we can use. Managing bugs through mail and forums must be hell.
Perhaps Prop's could set the standard and offer a common tool?
Selig Audio, LLC
In the above image it's a swept sine, split so the same signal goes into both the Ref and main input.Shokstar wrote:the Ref source was a sinewave sweep and what sound source was ducked by the sinewave sweep? A sinewave, white noise, a pad?selig wrote:
In the other two images I used a static sine wave for the Ref input, then tested the frequency response of the main path to see what it was doing.
Both techniques show the same result.
Selig Audio, LLC
For everyones convenience I attach an example where its easy to hear and see the issue Selig reported.
(Play the "Combinator 1" track with your keyboard, watch Spectrum EQ window) Just remove the .txt suffix...seems there is a file type filter preventing me to attach a Reason file (can that be fixed somehow?)
EDIT: Prerequisite: Antidote...
(Play the "Combinator 1" track with your keyboard, watch Spectrum EQ window) Just remove the .txt suffix...seems there is a file type filter preventing me to attach a Reason file (can that be fixed somehow?)
EDIT: Prerequisite: Antidote...
The other examples in the thread you linked were static tones in both inputs, similar to what you would get if you used a sub kick to "Carve" a bass.jappe wrote:I think it was a sine Sig In- the same as used for Ref In; He used a sine in the investigation in this thread: http://reasontalk.com/viewtopic.php?f=7&t=7490649Shokstar wrote:the Ref source was a sinewave sweep and what sound source was ducked by the sinewave sweep? A sinewave, white noise, a pad?selig wrote:
EDIT: eh...my bad...it's obviously not the same sine in sig in as in ref in since he measures ducking of other frequencies than in ref in...
I guess it could still be a sine in sig in that he sweeps after changing the ref in sine frequency
These should be the easiest for such a device to handle.
One application of Carve would likely be to send the kick to the REF input, and then process the bass. The result should be that the bass has the kick frequency "ducked" but only when the kick is playing. The issue I've seen would affect this process since it is typical for a kick to have a fundamental frequency of between 50-60 Hz, which is where the "bug" is most obvious. In stead of ducking just that frequency, Carve is also ducking above and below that frequency (45 Hz and 85 Hz) as shown in my second image above, the end result a ducking bandwidth from 20 Hz to 150 Hz (almost 3 octaves wide). In this case, assuming the kick frequency doesn't move, you can get far more precise results with a simple dynamic EQ setup (RE or Combinator), which will have a more precise frequency response (potentially more narrow as well), control over the exact dB level being ducked, and a much faster response time (a few ms vs over 100 ms) when using the MClass Compressor/EQ in a Combinator.
Selig Audio, LLC
I really appreciate selig taking the time to do such detailed tests. Giles, you are to frequency graphs what I am to performance tests LOL - you really put the RE's through the ringer (and rightly so).
I find what you presented quite concerning, and in the meantime I am going to put carve to use for it's intended purpose (ie ducking the low end to make room for both bass and kick) and see what result I get. I might also use it in the mid range somewhere as I am using multiple pads in this track, to see if i can make all the pads blend better.
The thing is, and my question here.. even if carve is totally inaccurate, can't it still be tuned by ear to sound right? So the frequency is off, move it till it sounds right, the amount of ducking varies with frequency, move the amount knob till it sounds right.. doesn't that make the most sense?
The thing is, if Ochen fixes it, everyone's projects thus far that use carve, and i bet there are a lot of users of it, will sound different. I am unaware how he could fix it without changing all current saved projects that use it. All ears for any ideas!
I find what you presented quite concerning, and in the meantime I am going to put carve to use for it's intended purpose (ie ducking the low end to make room for both bass and kick) and see what result I get. I might also use it in the mid range somewhere as I am using multiple pads in this track, to see if i can make all the pads blend better.
The thing is, and my question here.. even if carve is totally inaccurate, can't it still be tuned by ear to sound right? So the frequency is off, move it till it sounds right, the amount of ducking varies with frequency, move the amount knob till it sounds right.. doesn't that make the most sense?
The thing is, if Ochen fixes it, everyone's projects thus far that use carve, and i bet there are a lot of users of it, will sound different. I am unaware how he could fix it without changing all current saved projects that use it. All ears for any ideas!
Hey Theo, there are two things that IMO you can't work around. One is the "double dip" issue that falls right in the sweet spot for what you talk about using Carve for. The second is the unpredictable amount of delay before the attack phase begins, which if it was a static amount you could easily work around (and why I suggested a mode that induces a fixed delay).Theo.M wrote:I really appreciate selig taking the time to do such detailed tests. Giles, you are to frequency graphs what I am to performance tests LOL - you really put the RE's through the ringer (and rightly so).
I find what you presented quite concerning, and in the meantime I am going to put carve to use for it's intended purpose (ie ducking the low end to make room for both bass and kick) and see what result I get. I might also use it in the mid range somewhere as I am using multiple pads in this track, to see if i can make all the pads blend better.
The thing is, and my question here.. even if carve is totally inaccurate, can't it still be tuned by ear to sound right? So the frequency is off, move it till it sounds right, the amount of ducking varies with frequency, move the amount knob till it sounds right.. doesn't that make the most sense?
The thing is, if Ochen fixes it, everyone's projects thus far that use carve, and i bet there are a lot of users of it, will sound different. I am unaware how he could fix it without changing all current saved projects that use it. All ears for any ideas!
Other than that, what you describe will work with some tweaking. As far as I know, the plugin that may have inspired Carve, Track Spacer, doesn't have these issues (I've not tested it myself though), and if that is true it gives us hope that these issues can be tackled at some future point in time.
Selig Audio, LLC
Giles would it be better then to use something like CodeDiggers DQ Dynamic Processor rather than Carve? How else might this be achieved? Perhaps using cv out from a compressor to reduce frequencies using cv in on an EQ device?selig wrote:In this case, assuming the kick frequency doesn't move, you can get far more precise results with a simple dynamic EQ setup (RE or Combinator), which will have a more precise frequency response (potentially more narrow as well), control over the exact dB level being ducked, and a much faster response time (a few ms vs over 100 ms) when using the MClass Compressor/EQ in a Combinator.
Thanks
Hey folks. Just seeing this now. I'll remind your guys that I don't follow this forum that often, so I don't see things like this very quickly. I don't mind public discussions of issues with any of my devices, but if anyone's interested in actually identifying issues with the hope of improving the device and/or user experience, you should email me too. Just posting here, without emailing me directly, would seem to indicate less interest in actually identifying bugs to improve a device, and more interest in just slagging me and/or my devices. I guess you're free to do that, but it seems like bad form.
As to the issue, the EQing portion of Carve is 48 band EQ. Those bands have set frequencies. If a specific frequency needs to be ducked between any two bands, the adjacent bands do the best they can to average the duck. In real-world applications, you never need a single sine duck a single sine, so it's easy to show the limitation, as selig's done, if you just send a single frequency that sits right between two EQ bands. But in real-world applications, it's very rare that you'll have a single frequency in either the reference or signal audio chains, and so using real-world audio, the frequency smearing is much greater than the distance between bands. That's why when people use Carve by ear, using real-world audio sources, Carve works great.
I'm happy to revisit the distribution and bandwidth of the 48 bands, but I'm not going to change them to address a test case that doesn't exist in the vast majority of real-world applications. If there's a real problem in the real-world, I'll happily work on that. It sounds like there might need to be more bands covering the bass area. I'll see if moving some of the higher bands down causes problems elsewhere. If the mids and highs still sound okay, I'll release an update.
As to the issue, the EQing portion of Carve is 48 band EQ. Those bands have set frequencies. If a specific frequency needs to be ducked between any two bands, the adjacent bands do the best they can to average the duck. In real-world applications, you never need a single sine duck a single sine, so it's easy to show the limitation, as selig's done, if you just send a single frequency that sits right between two EQ bands. But in real-world applications, it's very rare that you'll have a single frequency in either the reference or signal audio chains, and so using real-world audio, the frequency smearing is much greater than the distance between bands. That's why when people use Carve by ear, using real-world audio sources, Carve works great.
I'm happy to revisit the distribution and bandwidth of the 48 bands, but I'm not going to change them to address a test case that doesn't exist in the vast majority of real-world applications. If there's a real problem in the real-world, I'll happily work on that. It sounds like there might need to be more bands covering the bass area. I'll see if moving some of the higher bands down causes problems elsewhere. If the mids and highs still sound okay, I'll release an update.
ochenk wrote:Hey folks. Just seeing this now. I'll remind your guys that I don't follow this forum that often, so I don't see things like this very quickly. I don't mind public discussions of issues with any of my devices, but if anyone's interested in actually identifying issues with the hope of improving the device and/or user experience, you should email me too. Just posting here, without emailing me directly, would seem to indicate less interest in actually identifying bugs to improve a device, and more interest in just slagging me and/or my devices. I guess you're free to do that, but it seems like bad form.
As to the issue, the EQing portion of Carve is 48 band EQ. Those bands have set frequencies. If a specific frequency needs to be ducked between any two bands, the adjacent bands do the best they can to average the duck. In real-world applications, you never need a single sine duck a single sine, so it's easy to show the limitation, as selig's done, if you just send a single frequency that sits right between two EQ bands. But in real-world applications, it's very rare that you'll have a single frequency in either the reference or signal audio chains, and so using real-world audio, the frequency smearing is much greater than the distance between bands. That's why when people use Carve by ear, using real-world audio sources, Carve works great.
I'm happy to revisit the distribution and bandwidth of the 48 bands, but I'm not going to change them to address a test case that doesn't exist in the vast majority of real-world applications. If there's a real problem in the real-world, I'll happily work on that. It sounds like there might need to be more bands covering the bass area. I'll see if moving some of the higher bands down causes problems elsewhere. If the mids and highs still sound okay, I'll release an update.
Selig's post was absolutely NOT bad form at all, and TBH your post suggesting so comes across as the one with bad form. We all know direct email is in some cases (obviously yours) a preferred way to communicate with the dev directly.. in this case, we are having a discussion amongst users and trying to replicate issues between us - if i hadn't seen this post i wouldn't have known of the issues, and to this day i have only used carve as a special FX so haven't done any bread and butter mixing with it and i find posts like this invaluable. This is absolutely the place to openly discuss bugs and findings on ANY re we have any kind of problem with..Go ask the owner of the site if we are not allowed to discuss issues we come across with RE's here...
If something we post about turns out not to be a bug, then the poster usually apologises. In fact, always apologises if needed going from previous topics. I haven't seen an ounce of poor posting in this topic until now.
That said, the rest of your post was very welcome and we appreciate the explanation that the 48 band EQ is the limitation. What you omitted however was a reply about why the AMOUNT of reduction wildly varies across different frequencies. I will be sure to email you so I can get a direct reply to that one if that's what you prefer. Cheers.
-
Puckboy2000
- Posts: 265
- Joined: 22 Mar 2015
- Location: SoCal
How would you tune it by ear? Using the hi pass and lo pass to move the parameters left and right? ThanksTheo.M wrote:I really appreciate selig taking the time to do such detailed tests. Giles, you are to frequency graphs what I am to performance tests LOL - you really put the RE's through the ringer (and rightly so).
I find what you presented quite concerning, and in the meantime I am going to put carve to use for it's intended purpose (ie ducking the low end to make room for both bass and kick) and see what result I get. I might also use it in the mid range somewhere as I am using multiple pads in this track, to see if i can make all the pads blend better.
The thing is, and my question here.. even if carve is totally inaccurate, can't it still be tuned by ear to sound right? So the frequency is off, move it till it sounds right, the amount of ducking varies with frequency, move the amount knob till it sounds right.. doesn't that make the most sense?
The thing is, if Ochen fixes it, everyone's projects thus far that use carve, and i bet there are a lot of users of it, will sound different. I am unaware how he could fix it without changing all current saved projects that use it. All ears for any ideas!
"Think of how stupid the average person is, and realize half of them are stupider than than that" - George Carlin
Hey Theo. Thanks for your perspective. I do want to note that in my reply, I explicitly said that I'm totally okay with people talking about any issues with my devices in this or any other forum. I also explicitly said that it's totally up to any individual as to whether they email me in addition to or instead of posting their reflections here or in any other forum. So we both completely agree. This is a great place to discuss issues. I only pointed out that when a person who knows that I don't read these forums very often posts here but doesn't also contact me directly, it comes off, to me at least, that getting the issue addressed may not be the primary motivation for discussing the issue. Again, that's totally up to the poster and they have no obligation to report the issue to me directly. It's not how I'd handle it, but there's no requirement to handle it differently.
As for you question about the amount of reduction, at this point, I can't reproduce it. Selig uses tools that aren't in Reason and that I don't have, so his setup is different than mine. But I'll continue to look into it.
As for you question about the amount of reduction, at this point, I can't reproduce it. Selig uses tools that aren't in Reason and that I don't have, so his setup is different than mine. But I'll continue to look into it.
-
- Information
-
Who is online
Users browsing this forum: Sogou [Spider], Trendiction [Bot] and 46 guests
Share and download patches!
Join ReasonTalk on Slack!