Forum Replies Created
-
Posts
-
Want to let you know that I’m the next days away from home/studio/computer – so I’ll test again when I’m back and being curious what happens in the meantime.
” title=”Smile” />OK, now I got it. Also the Juce demo causes the CPU increament very high when tweaking some parameters..
So: what does it mean for us Mac users now? Will Ctrlr stay like this (until Jules [i:27p53hi7]maybe[/i:27p53hi7] would fix it)?OK, I clicked the link above… downloaded it… open the .dmg… and see an icon which looks like half an orange… when I click this "The Jucer" opens… but I can’t find the option "Demo->Widges"…?
On the other habd I assume that if this causes in YOUR case high CPU peaks – it should be the same in MY case!?OK, if you want that we test something – please tell exactly(!) what to do. I never used this Juce nor Widged or whatever. Don’t want spend hours on that. I’ve downloaded it… open Juce…. and now?
If this costs too much time for you atm – no problem if this issue will stay for some time, because there is an alternative: just take the standard uiToggleButton. I think the other bugs which making Ctrlr "useless" (at least on Mac) should have priority!?
I recognised that you implemented this "true & false values" for an ImageButton – thanks for this! But it seems to be very buggy, though a normal ToggleButton works great.
I can see in the MIDI monitor that if I set "Value for ON state" to "127" – then I control the synth with Ctrlr… Ctrlr always send the same value (1). It doesn’t toggle at all. I recognise that the MIDI message is sent 2-3 times by Ctrlr, though I only pressed the button once."atom":2fgh6u8o wrote:Just wanted you to know i haven’t forgotten i just didn’t have enough time on my hands to do a proper build, however what i managed to do in the meantime– some performance fixes (very important ones and less important ones)[/quote:2fgh6u8o]
Did you really managed it and have you tried it out before the upload of 526? It’s the same like before. Very easy example: Take the standalone version, open a new pannel & select a MIDI out device, create a slider & use it.
You’ll recognise immediately that the CPU usage increases extremely in "Activity Monitor" (Mac). It’s about 10%-20% per EACH component on my 2.66 GHz Quadcore!Correct me when I’m wrong, but I can’t find the passage in which atom was writing about "multi sampling" – would this be possible (of course it will, but could it be done easy with just one click)? Appart from "multi sampling": Where is the big advantage to do this in Ctrlr and not in your DAW? For me a DAW is already a perfect "sampler", you can zoom in/out very precise, you can copy/paste/cut different parts of the sample (and find the "zero flat point") very easy, you can mix effects to your sample, you can reverse the sample, …. anything I can imagine is already possible – honestly, do I miss the benefit if Ctrlr would be possible to do sampling aswell? Please give an example.
Another thought: In the last years I absolutely prefer analogue synths. Though I really love my audio interface, everytime when I’m doing A/D conversions I’m a bit afraid about the digital character it gets. To be added that different samplers have different soundqualities. Whats about the soundquality of Ctrlr? If this sampler function will be implemented: Will Ctrlr be able to keep up with the audio quality of other professional samplers? Or depends the recording quality just 100% on the quality of your A/D converter and the format you choose? Maybe the audio differences of samplers just depend on how they PLAY the sample (not record!)?
Yeah ok, you just have to know that I’m a bit paranoid when thinking about implementing new features again.
” title=”Wink” /> Actually Ctrlr already offers (almost) everything you need for hardware integration (at least for me).
Because of new features (often they caused new bugs – but this behaviour is common) there wasn’t a Ctrlr version until now which works for me and which I like to use in a project (Maschine/Mac) – that’s why I’m really curious about the upcoming release…If I really can be honestly – I can’t see the big benefit for me so that I would change my current workflow of sampling (IF I do it.. I do in my DAW/host anyway).
Another thought: Because I like to use (and can imagine many others do aswell) multible Ctrlr plugins within a host project – I’m asking myself: when Ctrlr would become a multi tool (with sampler) if the CPU/RAM/whatever usage will increase? Even if each single Ctrlr plugin "just" would need 2% of my CPU… 15 Ctrlrs still would need together 30% of my CPU – this would be too much for my purposes – particulary when I don’t need the sampler function.Further thoughts: Much more I would love if the current focus of Ctrlr v5 development is more localised in the "source idea" of Ctrlr to achieve a 100% working "hardware/software-interation-bridge". Certainly I don’t know the point of time when you maybe like to implement this sampler but it would be nice to finish the basic idea before starting a completely new one (not alone because new implemented functions always causing new problems/bugs)… in the current Ctrlr version there are still some features which are not implemented (e.g. receive/translate Sysex dumps), not finished programmed features and main bugs (e.g. MIDI input breaks).
Then if the basic idea (a hardware/software bridge) of Ctrlr is ready programmed – it would be great to arrange first a bigger beta-test (with more users) to get Ctrlr 100% bugfree and that it runs on every system without any problems. Then we could gain a rock solid base for further ideas (maybe a Ctrlr v5.1?).Of course this is just my individual opinion – the decision is yours and I’m curious about further thoughts…
” title=”Smile” />As far as I know:
Changing component type: No, though it would be helpful. In older Ctrlr releases it was possible by changing the name from uiSlider to uiImageSlider (then save/reload the pannel) but now this name isn’t modifiable anymore.
Copy parameters: It’s just possible to copy/paste the multi message list and the Sysex formula.Thanks for the explanation. Though I’m still wondering why:
a) ALL other plugins (even Ctrlr v4) I’ve ever used, just need 1-2 seconds to close even if they get loaded 1.000 times – Ctrlr 486 would need in this case more than half an hour!
b) older Ctrlr releases "never" caused a crash when they get removed (OK, actually in some VERY old Ctrlr releases (around build 350) there was in 2-3 releases this "crash when Ctrlr get closed bug")But as I told I could live with a reduced delay of a quarter in compare to the current needed time, though it still seems strange to me (as a non-programer) why only Ctrlr has this problem.
Multible Ctrlr versions: On Mac I really never had problems with them. I could open Ctrlr 12 times (for 12 MIDI channels) – and there is completely no issue, everything works great!
… I’ve tested Maschine/Ctrlr on PC. Also here I can’t notice any problems in terms of closing AND in terms of multible Ctrlr plugins. The different Ctrlr plugins get automated and they sended different MIDI messages to different MIDI channels – without a crash or whatever. Though I’ve to add that I haven’t the possibility to connect my synths to that PC – but I assume it also should work.Though I still can’t notice the advantage of this delay feature – if the delay could be reduced to a quarter of the needed time… I [i:3djp2ij9]could[/i:3djp2ij9] live with that (though bigger projects still would need to close them ~ 30 seconds, these days this is still a huge amount just for closing a project). I’m really curious if the next fix will solve some of my problems (it could be the first usable Ctrlr version for me – since 2 months).
Yeah sorry, it costed me soo much energy (now and the last 2 months) to get Ctrlr bug-free (on Mac) – and I really can’t follow your arguments (substantially: yes – but not the decision).
I can tell you that Ctrlr never crashed the last months on Maschine or Ableton when the hosts get closed (and I’ve closed them in terms of tests maybe 1000 times(?) in the last month).Please tell me: why this big closing delay JUST happens in the combination Mac/Maschine? As I told: ALL other systems (OS vs host) are working well!
EDIT because of your edit:
” title=”Wink” />
Yeah I know that Windows is your preferred (better known) OS. And it’s nice that you anyway programing Ctrlr for Mac (but this delay when closing really let me think about to stay on 475).But for WHAT is that great feature??? In all release before 485 everything work well! Why to change this?? And why it’s just in Maschine on MAC (EVERYWHERE Ctrlr 485 works PERFECTLY… But not in the combination Mac/Maschine!)?
No – i really don’t need the answer: "because Maschine is a bad host – and Mac is a bad OS".OK – I can’t anymore. It costs me often a way too much energy (like now), that you’ll exept a bug as a bug.
Fault by the host? – No! … on PC I can load 1.000 Ctrlr plugins in Maschine – needed time to close: ONE second
Fault by Mac? – No! … on Mac I can load 10.000 other plugins (not Ctrlr) in Maschine – needed time to close: ONE second
"Fault" by the way Ctrlr works? – No! Before 485 everything worked well. EVEN 485 works on PC (Maschine, Ableton, whatever); on Mac: Just not with Maschine!
Fault by the Lord? – MaybeSorry I’ve the feeling I can write what I want – you’ll never exept it. If this bug (yes: bug) will not be solved… I’ll try to get happy with 475 (this nasty CPU monster) – and I’m out.
Sorry, I don’t think that "multible copies of Ctrlr loaded in one host" is the problem (at least not on Mac). As I wrote: in ALL versions before 486 it worked well (just a short time to close the project/host).
… and as I also told: Even just ONE single Ctrlr plugin loaded in Maschine causes a "big" delay when it get removed (486: 4 seconds… in older releases (<486) ONE single plugin just needs: ~ 0.2 seconds).
The amount of "50 seconds" I was talking about before is just the multiplier of 12*1 Ctrlr plugin (ok, actually it’s exactly 48). An other reason why it doesn’t depend on "multible Ctrlrs": In Ableton everything works as before (removing 1 plugin: ~0.2 sec – removing 12 plugins: ~ 2 sec).OK, no problem. As I told you don’t have to take the Tetra panel – even with an empty/complete fresh panel/Ctrlr this problem should appear. Did you try to load some more Ctrlr plugins (instead of one) in the Maschine project? In my case each(!) loaded Ctrlr VST/AU needs about ~ 4 seconds to close it (12 VSTs/AUs: ~ 50 sec). In older releases 12 plugins needed about 2 seconds to close. Maybe you should test this issue with some more Ctrlr plugins to notice the delay better?
