Repro V1.1 Release Candidate Rev 6780

Official support for: u-he.com
Locked New Topic
RELATED
PRODUCTS

Post

tasmaniandevil wrote:
zvenx wrote:Actually now I have gone thru all 900 presets and tagged my favourites on the PC it takes like 23-26 seconds.
Certainly a workflow killer, for me anyway.
That's certainly not expected. Even the seven seconds you mentioned before already sounded weird. I will send your database to Frank, maybe he can spot if there is a problem with it. I'll contact you via support mail soon, so we can figure this out.
I made a few tests last night, used a very old (non-SSD) external hard disk connected via USB2, and placed my Repro-1.data folder on it. I gave favourite or junk tags to all the 900+ factory presets. And even on this old external hard drive, a refresh of the database took just a little over one second.
Had a hunch but alas it didn't pay off.
I temporarily removed the two databases in Windows 10 (moved them to the desktop)
Repro-5 showed presets immediately, Repro-1 didn't was doing a rebuild and I said ah hah it has a favourites.whateveritwas file so it was rebuilding from that........
so I deleted the new databases files and removed the favourites.whateveritwas file to the desktop......both Repro1 and Repro5 showed presets immediately.
However when I put back the database files, they went back to the long update, and not just the first time.
rsp
sound sculptist

Post

Urs wrote:
Amram wrote:i saw before in one of the posts/threads that urs said that one of u-he team working on prophet 5 syx connvertor to repro5 .
when this convertor app release?
Might happen next week as well, not sure. I guess it'll be a separate download and maybe it needs some more work.
I am happy about that upcoming converter also to convert the commercial Prophet 5 Rev3.3 Sysex bank i bought a while ago (which i alraedy mentioend in the other thread).

In a Youtube video i also noticed another Prophet 5 bank i might buy when the converter is out.
This is from the same sound designer where i alraedy got banks for my DW-8000 and ESQ-1.
He only seems to sell via contact info at his Youtube channel.
Ingo Weidner
Win 10 Home 64-bit / mobile i7-7700HQ 2.8 GHz / 16GB RAM //
Live 10 Suite / Cubase Pro 9.5 / Pro Tools Ultimate 2021 // NI Komplete Kontrol S61 Mk1

Post

zvenx wrote:or did you mean 2 seconds?
you have made 900 presets already?
damn
Twenty seconds from when I first initiate the plugin.

(Most of the 900 presets are slight variations that will get thrown out. Maybe 100 are worth keeping.)

Post

hakey wrote:
zvenx wrote:or did you mean 2 seconds?
you have made 900 presets already?
damn
Twenty seconds from when I first initiate the plugin.

(Most of the 900 presets are slight variations that will get thrown out. Maybe 100 are worth keeping.)
on an ssd I imagine that also may be exhibiting the issue I have.
Thanks
rsp
sound sculptist

Post

u-he-william wrote:
Elektronisch wrote: When i turn off Multicore synth CPU use shoots from 21% straight to 54%. This is on FL Studio 12.5.1

Now on Studio One 3.5 (with latest patch) same Patch SD Echocrush on same midi with MC on use 25% and with MC Off shoots up to 53%. Changing thread count in Studio One doesnt do much. For example going from 4 to 8 threads only changes by 1% increasment in perfromance.

EDIT: Apearently newer patch for SO3.5 just came out recently and with it CPU use with MC on is 20% and MC off 52%. Changing thread number from 4 to 8 makes 3% percent increasment.
"Using 8 MC threads increase performance by 4%. Is it normal or too small increasment?"
What did you mean with that then? I thought the difference between MC off and MC on is 4%. :D
Well if i select more threads to be used logicaly there should be some significant boost (at least thats how i think, but im not really a software developer so i dont understand how much bigger number of threads can mean) :)

Post

zvenx wrote:on an ssd I imagine that also may be exhibiting the issue I have.
Looks that way. I'll maybe investigate further.

Post

Elektronisch wrote: Well if i select more threads to be used logicaly there should be some significant boost (at least thats how i think, but im not really a software developer so i dont understand how much bigger number of threads can mean) :)
Ahh, it depends on quite a few factors. In general, making a voice run on a different thread creates overhead. (You have to notify that thread to do some work and then synchronize with it again later on. Additionally, we can't force the OS to start processing that thread immediately). So with every additional thread, the overhead gets bigger relative to the boost you get from running stuff on multiple threads and thus the performance increase slows down.

Post

Urs wrote:
PhilG wrote:
4damind wrote:Great and good to see an improved multi-thread/multi-core handling :tu:
In my case it feels just like the opposite.

Many 8 voice patches cause crackles here with a single note played.
Multi Core on/off doesn´t have a large impact.

3rd Gen i7 3630QM, 256 buffer size, Windows 10 Pro 1709 64bit
Try experimenting with the number of threads setting in the preferences. I reckon that No. of physical cores - 1 is a good idea, so 3 threads on a quad core machine.
Oops, my mistake.
Forgot that I put it to 2 cores and upgraded CPU a few weeks later.

Post

Hello

Will the randomizers work with the official version ?

I need them very much...
Professional technicians are assessed by the abilities they possess.
Amateur technicians are assessed by the tools they possess - and the amount of those tools, with an obvious preference to the latest hyped ones.
(Gabe Dumbbell)

Post

Tp3 wrote:Hello

Will the randomizers work with the official version ?

I need them very much...
Nope... they would have to be adapted to the new (internal) parameter IDs. We don't keep records of that as they change frequently, if not day by day.

Post

I am just going to be the annoying guy that says... can't wait for the Linux version! Hope the problems from the other thread got sorted :)

Have a great weekend everyone!

Post

duplicate post. apologies.
Last edited by synth_punk on Fri Dec 08, 2017 2:04 pm, edited 1 time in total.

Post

Urs, the anti-randomizer :)
Urs wrote:
Tp3 wrote:Hello

Will the randomizers work with the official version ?

I need them very much...
Nope... they would have to be adapted to the new (internal) parameter IDs. We don't keep records of that as they change frequently, if not day by day.

Post

Thank you for the explanation Urs/William. Do you recommend 4 core default or less or more ?
Urs wrote:
synth_punk wrote:2013 Mac Pro 6 core vader helmet RePro-5 overall cpu seems a bit lower now (4 core default), but core 1 peaking more than others (Logic 10.2.3/Sierra).
Therein lies the improvement. The one core that does a little more work is the core Repro-5 would be rendering on if Multicore wasn't enabled. We give that one an extra voice to render, and some housekeeping on the voices that don't need rendering. This ensures (more or less) that all other cores have finished their job before this one is done.

With the previous implementation we noticed that the main core had often been sitting idle, waiting for other threads to finish. That is part of the overhead I was talking about that cripples overall performance when too many instances have too many threads to work with.

You'll see a little more CPU on you DAW's meter than before but overall CPU increases far less, and very large spikes (e.g. when a mouse click or a UI draw blocks a thread for a millisecond or two) should be history now.
[/quote]
Last edited by synth_punk on Fri Dec 08, 2017 2:03 pm, edited 1 time in total.

Post

Ok, maybe it's a Logic X thing ? Which has always been on the mystical side.

Image
Urs wrote:
Urs wrote:
synth_punk wrote:2013 Mac Pro 6 core vader helmet RePro-5 overall cpu seems a bit lower now (4 core default), but core 1 peaking more than others (Logic 10.2.3/Sierra).
Therein lies the improvement. The one core that does a little more work is the core Repro-5 would be rendering on if Multicore wasn't enabled. We give that one an extra voice to render, and some housekeeping on the voices that don't need rendering. This ensures (more or less) that all other cores have finished their job before this one is done.

With the previous implementation we noticed that the main core had often been sitting idle, waiting for other threads to finish. That is part of the overhead I was talking about that cripples overall performance when too many instances have too many threads to work with.

You'll see a little more CPU on you DAW's meter than before but overall CPU increases far less, and very large spikes (e.g. when a mouse click or a UI draw blocks a thread for a millisecond or two) should be history now.
I spoke too soon. William just tells me voices are still distributed evenly... gosh... I could ahve sworn, but nevermind, we tried a lot of things. Seems that some other dynamic allocation model beat the model I just described, and I have no idea where the one core processing more comes from :oops:

Locked

Return to “u-he”