Let's talk reaktor 6.4

Modular Synth design and releases (Reaktor, SynthEdit, Tassman, etc.)
Post Reply New Topic
RELATED
PRODUCTS
Reaktor Reaktor Player

Post

Only if something is downloaded and installed through NA, those products get update announcements within NA.

Post

suppose there is an update to any 3rd party Block Pack, does the user get notified thru Native Access?
Yeah not through Native Access, but I'll send an email notifying of any updates and put up a post here..

Post

.. so let me get this straight, not sure I understood this new front patchable rack thing yet:

I can not make my own blocks front patchable, correct? I'm still stuck in the old modus operandi if I only want to use my own custom made blocks?
"Wisdom is wisdom, regardless of the idiot who said it." -an idiot

Post

bmanic wrote: Mon Apr 15, 2019 6:22 pm .. so let me get this straight, not sure I understood this new front patchable rack thing yet:

I can not make my own blocks front patchable, correct? I'm still stuck in the old modus operandi if I only want to use my own custom made blocks?
someone of NI has said, that they want to implement that, they have a way for it, but pressure from upstairs, or other decisions, has let them released this version.
it seems in future updates, you can make your custom made blocks available in racks, look at the NI forum, forgotten where it was, so many discussions.

so this is not.. the end... it seems.. but there were no promisses, schedules, target time, etc...

Post

bmanic wrote: Mon Apr 15, 2019 6:22 pm .. so let me get this straight, not sure I understood this new front patchable rack thing yet:

I can not make my own blocks front patchable, correct? I'm still stuck in the old modus operandi if I only want to use my own custom made blocks?
I't not quite so simple....

You can make your own Blocks front Patchable, but you can't use them in Racks. Unfortunately, the only way to save a non-racks patch that depends on the front panel cables, is to save it as a another instance of the complete ensemble - snapshots and presets don't store patch'n'play cable routings.
With blocks ensembles easily reaching 50 - 100 mb, saving libraries of sounds this way becomes completely impractical.
You also don't get the coloured patch cables outside of Racks.

Post

EvilDragon wrote: Mon Apr 15, 2019 5:38 pm Only if something is downloaded and installed through NA, those products get update announcements within NA.
thanks ED!!
makes sense i guess.

David mentioned to me in an email that you automatically get notified if there is an update available for his Blocks (he's using SendOwl for this).

Post

ccooll wrote: Mon Apr 15, 2019 6:34 pm
bmanic wrote: Mon Apr 15, 2019 6:22 pm .. so let me get this straight, not sure I understood this new front patchable rack thing yet:

I can not make my own blocks front patchable, correct? I'm still stuck in the old modus operandi if I only want to use my own custom made blocks?
I't not quite so simple....

You can make your own Blocks front Patchable, but you can't use them in Racks. Unfortunately, the only way to save a non-racks patch that depends on the front panel cables, is to save it as a another instance of the complete ensemble - snapshots and presets don't store patch'n'play cable routings.
With blocks ensembles easily reaching 50 - 100 mb, saving libraries of sounds this way becomes completely impractical.
You also don't get the coloured patch cables outside of Racks.
Ok well, I don't mind having to do the old "save the whole ensemble for each song" cumbersome file management thing we've had to do since forever.. I just want to make my own blocks front patchable with their built in system.

I mean there are other front patchable solutions for Reaktor in "core and native" format but they are clunky and horrible most of the time.. thus I was really happy to see the new front patchable system. Glad to hear that I can still upgrade my own modules to do this.
"Wisdom is wisdom, regardless of the idiot who said it." -an idiot

Post

bmanic wrote: Mon Apr 15, 2019 6:59 pm
ccooll wrote: Mon Apr 15, 2019 6:34 pm
bmanic wrote: Mon Apr 15, 2019 6:22 pm .. so let me get this straight, not sure I understood this new front patchable rack thing yet:

I can not make my own blocks front patchable, correct? I'm still stuck in the old modus operandi if I only want to use my own custom made blocks?
I't not quite so simple....

You can make your own Blocks front Patchable, but you can't use them in Racks. Unfortunately, the only way to save a non-racks patch that depends on the front panel cables, is to save it as a another instance of the complete ensemble - snapshots and presets don't store patch'n'play cable routings.
With blocks ensembles easily reaching 50 - 100 mb, saving libraries of sounds this way becomes completely impractical.
You also don't get the coloured patch cables outside of Racks.
Ok well, I don't mind having to do the old "save the whole ensemble for each song" cumbersome file management thing we've had to do since forever.. I just want to make my own blocks front patchable with their built in system.

I mean there are other front patchable solutions for Reaktor in "core and native" format but they are clunky and horrible most of the time.. thus I was really happy to see the new front patchable system. Glad to hear that I can still upgrade my own modules to do this.
see this post of philip d of NI in this thread:

https://www.native-instruments.com/foru ... st-1781221

also i already stated, the horizon isn't in sight yet...

also the bug, i didn't report it yet, but it has been reported, that when i load a rack, or ensemble, you get the default page of reaktor. so when outside reaktor, you click on a rack file.

so they are still working on it.

in the mean time i do my time in racks with toybox packs, and the hetrick free rack blocks..

and fool around in VM, and fool around in ensemble mode...

Post

At the risk of repetition:

Given that toyboxaudio and unfilteredaudio maintain storefronts outside of Native Access (so I assume NI is not taking a percentage of sales), I'm still confused as to why NI needed to go with a centralized system for unique block identifiers and not something akin to UUID, which is, for all practical purposes, guaranteed to be unique (unless someone creates an ID on your network at the exact same moment in time).

This would
1) allow users to registers their own blocks locally and have them work with the Racks ecosystem
2) still allow commercial developers to sell "locked" blocks that work with Reaktor Player.

NI is not creating a Blocks storefront similar to the App Store - to use Microsoft (again) as an example, only in the Windows App Store does one need to register and be approved, because Microsoft takes a percentage of sales. To develop applications for Windows, VisualStudio (and other tools) can create a unique 128-bit ID that allows installers for commercial and personal applications to coexist without a centralized registry.

Gotta be some dementia coming on (on my part) :)

Post

JoeCat wrote: Mon Apr 15, 2019 8:11 pm At the risk of repetition:

Given that toyboxaudio and unfilteredaudio maintain storefronts outside of Native Access (so I assume NI is not taking a percentage of sales), I'm still confused as to why NI needed to go with a centralized system for unique block identifiers and not something akin to UUID, which is, for all practical purposes, guaranteed to be unique (unless someone creates an ID on your network at the exact same moment in time).

This would
1) allow users to registers their own blocks locally and have them work with the Racks ecosystem
2) still allow commercial developers to sell "locked" blocks that work with Reaktor Player.

NI is not creating a Blocks storefront similar to the App Store - to use Microsoft (again) as an example, only in the Windows App Store does one need to register and be approved, because Microsoft takes a percentage of sales. To develop applications for Windows, VisualStudio (and other tools) can create a unique 128-bit ID that allows installers for commercial and personal applications to coexist without a centralized registry.

Gotta be some dementia coming on (on my part) :)
this is a quote from the NI forum (that i have given in alink to in an above post) from a someone of the NI team:

"We see your frustration around the user generated content problem. This is not a trivial problem, opposed to some of the assumptions posted here. When we started the project, there was a solution on the horizon, that made it possible to upload any user generated content via a portal (also for free), and making the best of both world possible: sharing, and the safety-net to have identifiable Blocks (which is crucial for a reference based file format). This obviously did not happen in time. Nevertheless we released it as it is, to give the 99% of our users who don't actually build a chance to play around with the new format, and to see what the people are missing / would like to see as an improvement - as for instance: semi modulars, that may store wires in presets. And it turned out: user generated content is a hot topic."

it seems that in a future update that portal will be made available. they released it as is, i paraphrase, but the development isn't on hold, on the contrary, it seems, there a more development tracks. but when they arrive?

look at the NI fora, look over the confusion, see what NI self is saying. it is remarkable, that in the threads about reaktor, a lot of NI people respond. and give a lot of info. but NI looks on top of it, or at least, members of the team.

i wish they do that in other forum topics too....

Post

WasteLand wrote: Mon Apr 15, 2019 8:22 pm
JoeCat wrote: Mon Apr 15, 2019 8:11 pm At the risk of repetition:

Given that toyboxaudio and unfilteredaudio maintain storefronts outside of Native Access (so I assume NI is not taking a percentage of sales), I'm still confused as to why NI needed to go with a centralized system for unique block identifiers and not something akin to UUID, which is, for all practical purposes, guaranteed to be unique...
this is a quote from the NI forum (that i have given in alink to in an above post) from a someone of the NI team:

"We see your frustration around the user generated content problem. This is not a trivial problem, opposed to some of the assumptions posted here...
Thanks for the info from the forum. I've been trying to keep up there too. For some reason when I clicked your link I was getting a proxy error.

From their quote:
"and the safety-net to have identifiable Blocks (which is crucial for a reference based file format)."

That's what UUID solves. For low-tech solutions some developers hash date/time and, for practical purposes, that works. So a commercial developer's block may has from 4/10/19 12:07:08 and yours from 4/15/19 14:12:84 - they'll have unique identifiers on the same system because the odds of any two hashes being generated the exact same moment in time (from a small population such as this) is very small. Add in a network identifier / pseudo-random number, and it's almost impossible to duplicate.

As a developer I'm just hung up on this because, unless there are other technical issues, this is an easily solvable one.

Post

What's going on I already own Reaktor 6 and today I get an email anouncing new paid content for reaktor but it all looks like the stuff I already have.

Ah I think I get it they made Reaktor 6 free and have extras as paid addons?

Nevermind I get it now the email confused me I already own it all somehow.
Last edited by I'm Ant on Mon Apr 15, 2019 8:51 pm, edited 1 time in total.

Post

Just posted that question of UUID's in NI's forum (I feel better now lol).

They have been very responsive and gripes aside, that's encouraging.

Post

Wow Toybox Audio have a lot of blocks I feel like a kid in a massive toy shop with 100k to spend.

Post

I'm Ant wrote: Mon Apr 15, 2019 8:49 pm Wow Toybox Audio have a lot of blocks I feel like a kid in a massive toy shop with 100k to spend.
Only you don't need anywhere near 100k! I just started playing with the free pack and think the $80 everything purchase is likely to be very worthwhile.
Sweet child in time...

Post Reply

Return to “Modular Synthesis”