@andy4trance
1. Dials' crackling because of a slower PC - need to check that with the guys if this may be a problem.
2. In theory, there are a lot of room for optimization. It requires deep research = a lot of time. We don't have free 6-8 months to do this right now. Our current plan is to bring few more products to the market and make smaller optimizations in the process.
3. The topic about requirements can be discussed endlessly, I think. There is not much I can say. I just believe that with time, more and more people will have an opportunity to use faster machines. Sooner or later we all have to upgrade to cope with the modern technologies.
@Baxterbrown
I'll reply tomorrow, going to bed now =)
Mercuriall released Spark
-
- KVRist
- 222 posts since 24 Dec, 2016
-
- Banned
- 892 posts since 23 Jan, 2011
I have a suggestion. How easily could put in an offline rendering option? It may help slower computers by allowing them to run at no sampling but render at 8x.Barmaleus wrote:@andy4trance
1. Dials' crackling because of a slower PC - need to check that with the guys if this may be a problem.
2. In theory, there are a lot of room for optimization. It requires deep research = a lot of time. We don't have free 6-8 months to do this right now. Our current plan is to bring few more products to the market and make smaller optimizations in the process.
3. The topic about requirements can be discussed endlessly, I think. There is not much I can say. I just believe that with time, more and more people will have an opportunity to use faster machines. Sooner or later we all have to upgrade to cope with the modern technologies.
@Baxterbrown
I'll reply tomorrow, going to bed now =)
-
- KVRist
- 222 posts since 24 Dec, 2016
@Baxterbrown
Sorry for delay, got carried away.
1. Cool. Now I know THE secret
I see. Yep, it should run Spark (heavily breathing, though).
2. Yep, I understand your point. Spark does require a fair amount of CPU power to run. This is the price for the technology used - again, we are not using EQ matching or wave shaping, we model the whole electric chain of devices and then train neural networks to run it in real time. Is there a room for improvement? Of course. It will take years to improve it, though. We are a very small team right now.
3. Right, I see. I think the only thing I can suggest right now is to track with lower oversampling and then bounce tracks with 8x oversampling into a mixing session.
@JJ_Jettflow
Sorry, don't know how difficult it is technically. I think in a list of potential new features it won't be on top, though. The solution is to manually change the oversampling when needed.
We'd want to spend development time on something that brings more value or has more requests from customers.
Sorry for delay, got carried away.
1. Cool. Now I know THE secret
I see. Yep, it should run Spark (heavily breathing, though).
2. Yep, I understand your point. Spark does require a fair amount of CPU power to run. This is the price for the technology used - again, we are not using EQ matching or wave shaping, we model the whole electric chain of devices and then train neural networks to run it in real time. Is there a room for improvement? Of course. It will take years to improve it, though. We are a very small team right now.
3. Right, I see. I think the only thing I can suggest right now is to track with lower oversampling and then bounce tracks with 8x oversampling into a mixing session.
@JJ_Jettflow
Sorry, don't know how difficult it is technically. I think in a list of potential new features it won't be on top, though. The solution is to manually change the oversampling when needed.
We'd want to spend development time on something that brings more value or has more requests from customers.
-
- KVRAF
- 5201 posts since 6 May, 2002
How could there be room for improvement if the whole electric chain has already been modelled?Barmaleus wrote: 2. Yep, I understand your point. Spark does require a fair amount of CPU power to run. This is the price for the technology used - again, we are not using EQ matching or wave shaping, we model the whole electric chain of devices and then train neural networks to run it in real time. Is there a room for improvement? Of course. It will take years to improve it, though. We are a very small team right now.
Intel Core2 Quad CPU + 4 GIG RAM
-
- KVRist
- 222 posts since 24 Dec, 2016
@electro
There are few things:
1. Digging deeper into assembler to review how algorithms work + optimizing location of the elements in memory for faster access.
2. Improving the architecture and training methods of neural networks, especially the poweramp module.
3. Other areas I may not be aware of.
Those are not trivial tasks and require extensive research.
There are few things:
1. Digging deeper into assembler to review how algorithms work + optimizing location of the elements in memory for faster access.
2. Improving the architecture and training methods of neural networks, especially the poweramp module.
3. Other areas I may not be aware of.
Those are not trivial tasks and require extensive research.
-
- KVRist
- 198 posts since 11 Oct, 2012
Any news on Spark updates from Mercuriall?
-
- KVRist
- 222 posts since 24 Dec, 2016
Yes indeed!
We've recently released Spark 1.1, it is available for download at www.mercuriall.com.
Here is the changelog:
- New stomp box based on BOSS SD-1
- New presets from Ola Englund*
- Improved plugin performance on Mac
- Improved performance of Windows 32bit plugin
- Improved AFD HI channel sound
- Fixed some issues in Delay settings
- Added "EQd cabs". These cabs have more even low end behavior.
*Unfortunately, presets are not available in the AAX version
We've recently released Spark 1.1, it is available for download at www.mercuriall.com.
Here is the changelog:
- New stomp box based on BOSS SD-1
- New presets from Ola Englund*
- Improved plugin performance on Mac
- Improved performance of Windows 32bit plugin
- Improved AFD HI channel sound
- Fixed some issues in Delay settings
- Added "EQd cabs". These cabs have more even low end behavior.
*Unfortunately, presets are not available in the AAX version
-
GrabtharsHammer GrabtharsHammer https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=377531
- KVRian
- 503 posts since 7 Apr, 2016 from Bünde, Germany
Astonishing amp sim. Purchased it just yesterday and really can't praise it highly enough. I haven't been this euphoric about an amp sim since the release of Kazrog's Thermionik 5 (which is amazing, too). But in regards to Marshall tones this one is even better. Everyone who hasn't tested it yet and likes Marshall sounds - give it a chance!
-
- KVRist
- 198 posts since 11 Oct, 2012
Mercuriall products have something pleasing in the distortion (subjective assessment ofcourse), something that is across products, meaning unrelated to the amp modeled but probably to their code.
So, still have hope that Spark's CPU usage will be improved for the 64bit version.
The Engl model sounds very good too, and it's much lighter on resources, so keeping my eyes on this.
Not yet sure that the 32 is better than the 64 due to gbridge.
So, still have hope that Spark's CPU usage will be improved for the 64bit version.
The Engl model sounds very good too, and it's much lighter on resources, so keeping my eyes on this.Not yet sure that the 32 is better than the 64 due to gbridge.
-
- KVRer
- 4 posts since 5 Mar, 2017
I am using Ableton Live 9. The 64 bit version of this plugin indicates 50% usage in Ableton at 2x or 4x oversampling. At 8x it is over 100% - again as reported in Ableton. Actual CPU usage is only about 20%, as reported from the task manager. The plugin is not usable at these usage levels in Ableton - any additional load causes dropouts.
HOWEVER - the 32 bit version - through jBridge indicates 15% load in Ableton at 2x, about 20% load at 4X and about 40% load at 8x. At 2x or 4x it is absolutely stable - no dropouts.
**Therefore, there is no debate here - using Ableton, anyway. There is something seriously wrong with the 64 bit version of the plugin. This seems to echo the experience of other users.**
This isn't a problem for me - jBridge works perfectly for this plugin but hopefully the problem with the 64 bit version will be rectified. I only posted this because there seemed to be some confusion about whether there is an issue with load as indicated by DAW hosts for the 64 bit version. There IS an issue - at least for some hosts.
Not to be negative here - this is an amazing plugin, with an unmatched emulation of Marshall amplifiers. I really want to use this live. However, for last night's gig I had to "downgrade" to using the s-gear sim (which is also a fantastic sim) simply because of the behavior of Spark in the DAW. It was only this morning that I had time to check 32 bit version of Spark and discovered what I posted above.
Anyway, I hope that is helpful to some users and is informative to the developers.
HOWEVER - the 32 bit version - through jBridge indicates 15% load in Ableton at 2x, about 20% load at 4X and about 40% load at 8x. At 2x or 4x it is absolutely stable - no dropouts.
**Therefore, there is no debate here - using Ableton, anyway. There is something seriously wrong with the 64 bit version of the plugin. This seems to echo the experience of other users.**
This isn't a problem for me - jBridge works perfectly for this plugin but hopefully the problem with the 64 bit version will be rectified. I only posted this because there seemed to be some confusion about whether there is an issue with load as indicated by DAW hosts for the 64 bit version. There IS an issue - at least for some hosts.
Not to be negative here - this is an amazing plugin, with an unmatched emulation of Marshall amplifiers. I really want to use this live. However, for last night's gig I had to "downgrade" to using the s-gear sim (which is also a fantastic sim) simply because of the behavior of Spark in the DAW. It was only this morning that I had time to check 32 bit version of Spark and discovered what I posted above.
Anyway, I hope that is helpful to some users and is informative to the developers.
-
- KVRist
- 222 posts since 24 Dec, 2016
fortunjj,
Hi and thank you for all the feedback, appreciate it!
Could you let me know the following details of your computer, please:
1. OS
2. CPU model name
3. Overall RAM size and Free RAM size before you open the DAW
4. CPU load before you open the DAW
5. Your sound interface name and buffer settings/sampling frequency you run it at
6. Are you on HDD or SSD
This is purely for better understanding of what machine is used to run Spark.
Also, could you run an experiment to see if Spark would behave the same in another DAW on your computer? Please try to run it in Reaper (it is free to try http://reaper.fm/). Just want to see how it will behave in a different DAW on the same hardware.
Thanks a lot!
Hi and thank you for all the feedback, appreciate it!
Could you let me know the following details of your computer, please:
1. OS
2. CPU model name
3. Overall RAM size and Free RAM size before you open the DAW
4. CPU load before you open the DAW
5. Your sound interface name and buffer settings/sampling frequency you run it at
6. Are you on HDD or SSD
This is purely for better understanding of what machine is used to run Spark.
Also, could you run an experiment to see if Spark would behave the same in another DAW on your computer? Please try to run it in Reaper (it is free to try http://reaper.fm/). Just want to see how it will behave in a different DAW on the same hardware.
Thanks a lot!
-
- KVRer
- 4 posts since 5 Mar, 2017
Barmaleus,
I am using Windows 10, with an i7-5700HQ (laptop), 16 GB ram and a solid state drive.
3% CPU load before the DAW is opened with 25% memory used.
M-Audio M-Track @44.1 kHz sampling rate, 128 samples buffer.
I will certainly give both 32 and 64 bit versions a shot on Reaper. The only little issue I have is that in using jBridge, I found I could only have one version licensed at a time. Once I ran the 32 bit version, I had no license info for the 64-bit version. I would have to obtain another license (unless there is another way to set the license back up once the info has been wiped) each time I switched from 32 bit to 64 bit and vice versa. For whatever reason the two cannot coexist.
I am using Windows 10, with an i7-5700HQ (laptop), 16 GB ram and a solid state drive.
3% CPU load before the DAW is opened with 25% memory used.
M-Audio M-Track @44.1 kHz sampling rate, 128 samples buffer.
I will certainly give both 32 and 64 bit versions a shot on Reaper. The only little issue I have is that in using jBridge, I found I could only have one version licensed at a time. Once I ran the 32 bit version, I had no license info for the 64-bit version. I would have to obtain another license (unless there is another way to set the license back up once the info has been wiped) each time I switched from 32 bit to 64 bit and vice versa. For whatever reason the two cannot coexist.
-
- KVRist
- 222 posts since 24 Dec, 2016
fortunjj,
I see, thanks. This computer must be able to run Spark even at 8x oversampling just fine. Are there any other plugins in the project with Spark?
It feels like something is going on with Abletone indeed. Would be extremely helpful if you could run tests in Reaper. Then we can be 100% sure it has something to do with a DAW.
Re. the 32 and 64 bit versions - indeed, only one can be active at the same time. I hope we can change this in future.
Meanwhile, if you run out of activations on the web, just send us a support message through www.mercuriall.com and we will add more.
I see, thanks. This computer must be able to run Spark even at 8x oversampling just fine. Are there any other plugins in the project with Spark?
It feels like something is going on with Abletone indeed. Would be extremely helpful if you could run tests in Reaper. Then we can be 100% sure it has something to do with a DAW.
Re. the 32 and 64 bit versions - indeed, only one can be active at the same time. I hope we can change this in future.
Meanwhile, if you run out of activations on the web, just send us a support message through www.mercuriall.com and we will add more.
-
- KVRer
- 4 posts since 5 Mar, 2017
Barmaleus,
So I tried both the 32 bit and 64 bit versions in Reaper 64 bit. The problem is definitely with Ableton (Live 9.7). In Reaper, CPU usage is about 5% for both the 32 bit (with jBridge) and the 64 bit version even at 8x oversampling. In Ableton, the 32 bit with jBridge is about 15% (again, as reported by Ableton) and over 50% with only 2x oversampling. It isn't just in the way Ableton is reporting usage - I get dropouts with the 64 bit plugin.
One obvious answer for me would be to use Reaper. However, to be honest, I cannot stand the interface. I have used a number of DAWs over the years - Cakewalk, Sonar, Cubase / Nuendo and Ableton. Ableton is very intuitive and user friendly. I can get used to something different for recording but I prefer something simple for playing live, for obvious reasons. Another option I would have is Cantabile for live use, but I was trying to avoid buying yet another DAW. Additionally, Ableton has a great feature where I can easily map computer keyboard presses to any plugin parameter. I built a simple footswitch controller from an old USB computer keyboard and some momentary footswitches I had laying around. MIDI footswitch boards are horribly overpriced, IMHO.
Anyway, the problem is certainly DAW dependent, so that gives you some more information to go on. I hope that experiment was helpful.
So I tried both the 32 bit and 64 bit versions in Reaper 64 bit. The problem is definitely with Ableton (Live 9.7). In Reaper, CPU usage is about 5% for both the 32 bit (with jBridge) and the 64 bit version even at 8x oversampling. In Ableton, the 32 bit with jBridge is about 15% (again, as reported by Ableton) and over 50% with only 2x oversampling. It isn't just in the way Ableton is reporting usage - I get dropouts with the 64 bit plugin.
One obvious answer for me would be to use Reaper. However, to be honest, I cannot stand the interface. I have used a number of DAWs over the years - Cakewalk, Sonar, Cubase / Nuendo and Ableton. Ableton is very intuitive and user friendly. I can get used to something different for recording but I prefer something simple for playing live, for obvious reasons. Another option I would have is Cantabile for live use, but I was trying to avoid buying yet another DAW. Additionally, Ableton has a great feature where I can easily map computer keyboard presses to any plugin parameter. I built a simple footswitch controller from an old USB computer keyboard and some momentary footswitches I had laying around. MIDI footswitch boards are horribly overpriced, IMHO.
Anyway, the problem is certainly DAW dependent, so that gives you some more information to go on. I hope that experiment was helpful.
-
- KVRist
- 222 posts since 24 Dec, 2016
fortunjj,
Understood, thank you for the test. I will pass this on to our devs, I hope they can find out what's wrong.
Of course, I cannot tell you to use Reaper =) (just FYI, there are lots of cool UI themes for Reaper http://stash.reaper.fm/tag/Themes. I personally don't like their default skin).
Just wondering - is there any setting in Ableton that says how many CPUs it should use? If yes, is it using all your cores?
Understood, thank you for the test. I will pass this on to our devs, I hope they can find out what's wrong.
Of course, I cannot tell you to use Reaper =) (just FYI, there are lots of cool UI themes for Reaper http://stash.reaper.fm/tag/Themes. I personally don't like their default skin).
Just wondering - is there any setting in Ableton that says how many CPUs it should use? If yes, is it using all your cores?
