RE SDK question, for those who might know.

[platzangst]

Sample loading is, as far as I know, still not directly allowed in the RE system. One hopes it's coming down the line - eventually.

But in the meantime, I was wondering about possible workarounds. Consider that the System 9 sequencer can have its patches read by an external utility. Consider also that REs are able to load and save patches like other Reason devices.

So, would it not be at least theoretically possible to load a sample into an RE through the patch system itself? Imagine a utility built for some specific RE that converts one or more samples into generic data that is embedded in a patch file; when the RE loads the patch it also loads the waveform within, much like a Reason song can have its audio tracks and various samples embedded in its song files.

The downside, of course, would be that you'd have to wrangle with multiple steps to import waveforms, and maybe some users would be put off by the effort. On the other hand, it beats out any system currently available for REs.

But I don't know enough about the RE patch architecture to say if this is even possible. Nothing I've heard about it would seem to forbid it, but then again, I can't imagine why someone hasn't already tried this if it was do-able.

Any developers care to comment? Possible or not?

[Olivier]

Consider that anyone with access to the SDK is bound by an NDA. So noone can really comment. And as you say yourself, if there is a workaround, and props would allow devs to use it, i think we would've probably allready seen this

Lets see what we can learn from repatch files. I think you'll see that what you are saying may be technically possible.

Know that Repatch files are formatted in XML. XML is a standard anyone can read without fancy programs. They are "humanly readable". As an example i chose this one from Shape by Lectric Panda because it contains a huge amount of unintelligable data.

Code: Select all

    
        Shape LFO Editor
    
    
        
            
                410140303F603F0F3E3F3D6F3D1E3C4E3B7E3B2E3A5E3A0E393E386E381E374E367F36303560351134423374332532563208313A306C301E2F512F042E362D6A2D1D2C512C052B392A6D2A222957290C28422777272E2664261B25522509244123792332226B2224215E21182052200D1F481F041E401D7C1D391C771C341B731B311A711A30197019311872183417761738167B163F16031548150D1453141913601327126F12381201114B11151060102B0F770F440F110E5F0E2E0D7D0D4D0D1D0C6E0C400C120B650B390B0D0A620A380A0E0965093D0915086E08480822077D07590736071306710650062F060F0570055205340517047B045F0445042B041103790361034A0334031F030A027602630250023F022E021E020F0180017201650159014E01430139013001280120011A0114010F010A010701040102010101010101010201040107010A010F0114011A01200128013001390143014E0159016501720180020F021E022E023F025002630276030A031F0334034A036103790411042B0445045F047B0517053405520570060F062F06500671071307360759077D08220848086E0915093D09650A0E0A380A620B0D0B390B650C120C400C6E0D1D0D4D0D7D0E2E0E5F0F110F440F77102B10601115114B12011238126F1327136014191453150D15481603163F167B1738177618341872193119701A301A711B311B731C341C771D391D7C1E401F041F48200D20522118215E2224226B23322379244125092552261B2664272E27772842290C29572A222A6D2B392C052C512D1D2D6A2E362F042F51301E306C313A32083256332533743442351135603630367F374E381E386E393E3A0E3A5E3B2E3B7E3C4E3D1E3D6F3E3F3F0F3F6040304080415142214272434244124463453346034653472347734843491349634A334B024B514C214C704D3F4E0D4E5C4F2B4F795047511551635230527D534B541754645530557C56485714575F582A5875593F5A0A5A535B1D5B665C2F5C785D405E085E4F5F165F5D60236069612F61746239627D634164056448650A654D660E66506710675168116850690F694D6A0B6A496B066B426B7E6C396C746D2E6D686E216E5A6F126F496F807036706C71217156720A723D72707322735374047434746475137541756F761C76487674771F77497773781C7844786C79137939795F7A047A287A4B7A6E7B107B317B527B727C117C2F7C4D7C6A7D067D227D3C7D567D707E087E207E377E4D7E627E777F0B7F1E7F317F427F537F637F728001800F801C80288033803E80488051805980618067806D80728077807A807D807F808081018080807F807D807A80778072806D80678061805980518048803E80338028801C800F80017F727F637F537F427F317F1E7F0B7E777E627E4D7E377E207E087D707D567D3C7D227D067C6A7C4D7C2F7C117B727B527B317B107A6E7A4B7A287A04795F79397913786C7844781C77737749771F76747648761C756F75417513746474347404735373227270723D720A71567121706C70366F806F496F126E5A6E216D686D2E6C746C396B7E6B426B066A496A0B694D690F68506811675167106650660E654D650A644864056341627D62396174612F606960235F5D5F165E4F5E085D405C785C2F5B665B1D5A535A0A593F5875582A575F57145648557C553054645417534B527D52305163511550474F794F2B4E5C4E0D4D3F4C704C214B514B024A3349634913484347734723465346034533446344124342427242214151
            
        
    

Audio files can be captured and represented in a string. So in theory you can put that kind of data in there. It can then be reinterpreted by a RE as audio data.
But we also have to consider the following. Even though the repatch file is humanly readable, we don't know if props has set any constraints on its content. Maybe they set a maximum length on the type "string". In which case you may not be able to load more then a few milliseconds of sample with it. So i think its either in the constraints set on this, or the fact that props simply doesn't allow the use repatches for sample loading.

[note] I'm just a part-time programmer and registered dev... so i may be completely off here..

[platzangst]

Consider that anyone with access to the SDK is bound by an NDA. So noone can really comment. And as you say yourself, if here is a workaround, and props would allow us to use it, i think we would've allready seen this

The NDA hasn't prevented developers from talking in non-specific terms in the past; I'm not sure what they might be violating by discussing this. But if this next bit is true:

Also, know that all RE patches can be read easily because they are in XML format. Just save one from any device and open it up with a text editor.

...then it might very well be possible. After all, back in the day when there was no high-speed internet for most of us, and everyone was passing files on Usenet and such, it was quite common to use methods like UUencoding to translate digital files to blocks of gibberish text which could be downloaded and copied and translated back into usable files. Why not build an instrument with a UUencoder/decoder built in? Then a patch could have just a block of ASCII that could be turned into waveform data.

As near as I can see, the worst case scenario is that someone spends the time and effort making an instrument with this kind of workaround built in and then Propellerhead immediately releases SDK 4 or something and finally sampling is allowed.

[Benedict]

Maybe there is a hack like what you speak of but in reality I don't think it is worth developing as while a few people would be all "oh how cool, you stuck it to the man" the resulting workflow would be very clunky. Even if you managed to sneak a sample into an RE you would only have the one Patch to go along with it. If you wanted two Piano patches that is two huge Patch files. If you wanted three then...

[avasopht]

There may be a text limit. To find out, insert 5000 characters into s text property and see what reason does

[platzangst]

"Stuck it to the man"?

Sure, amassing stacks of files with big chunks of wave data would be a problem, and I already pointed out that the workflow wouldn't be great, but at this point, what's the alternative? Right now, we have to use the existing samplers, or kludge some way of using VSTs in other hosts, or do without and wait for Props to update the SDK (whenever that's going to be). If I actually thought Props were putting sample loading as a priority in future SDK development I wouldn't bother suggesting this, but at this point I just wonder what the holdup is.

Anyway, since we already have the NN19 and NN-XT, we wouldn't need a hack for using samples in the usual, basic ways. Why make a lot of piano patches for some imaginary sampler when we have perfectly good samplers for piano sounds - and a couple REs besides? No, if someone was going to do this, it would probably be for a sampler we don't have at the moment. Something like (to pick something being discussed elsewhere) Serum, for example. More experimental devices.

[Olivier]

There may be a text limit. To find out, insert 5000 characters into s text property and see what reason does

Good idea.. i put roughtly half a megabyte of data in there.. didn't crash anything
I have no idea what this tells us though. Did Reason really deliver all that data to the RE ? At least some of it got delivered because the device did get set up the way i wanted. With the correct curve.

But as Platzangst is implying.. sample loading is far overdue. I really don't get what the holdup is either. Introduce sample loading in the SDK and while you're at it update the sample editor. It will be such a great boost for the platform.

[PadShifta]

What´s the deal with being able to load samples into a synth anyway? Don´t get me wrong, if it´s awsome, then I want it!
But I simply never felt the need to try dropping some of my own samples onto any Vst synth that might be able to handle this. What´s it good for? Tell me what I have been missing out from please.

It´s a topic everyone seems to freak out about, so tell me why we need to have sample loading in synths.


Drawing my conclusions though, I feel that the Props are somewhat testing this in the overhaul of the RV7000 (mk2). I can drop anyone of my wav.files on it and it will process it. Now i know that it is a native device and the issues are about Rack Extensions and the Sdk.
But since this is a ".3"- update, we might see things like sample loading in future ".0"- releases!

Cheers, Andy

[Exowildebeest]

I suspect the RV7000 mkII is testing sample loading for RE too, but there's no direct confirmation of this.

Thinking of 'hacks' is nice, but as happened with MIDI-out, even if it's possible it probably wouldn't be allowed by Propellerheads.

[platzangst]

What´s the deal with being able to load samples into a synth anyway? Don´t get me wrong, if it´s awsome, then I want it!
But I simply never felt the need to try dropping some of my own samples onto any Vst synth that might be able to handle this. What´s it good for? Tell me what I have been missing out from please.

It´s a topic everyone seems to freak out about, so tell me why we need to have sample loading in synths.

The thing is, not having sample loading limits what can be done with samples in Reason.

Consider the Iris synth from Izotope. In that VST synth, you can drop a sample in and then manually draw a filter onto the wave display itself, leading to a wide variety of sample manipulations in ways that aren't currently convenient in Reason. Or Breaktweaker, also by Izotope, a feature-rich drum machine with a much different interface than, say, ReDrum. Or, up until now, convolution reverbs using custom impulses (see Diego Stocco's videos for an idea of what can be done). Or even experimental synths - granular, additive re-synthesis, and such. Even if you want to do something like set a couple of LFOs to modulate the start and end points of a sample loop, well, if it can't be done in the NN19 or NN-XT, you can't do it, and there's no 3rd party who can make an improved sampler RE until sample loading appears.

Drawing my conclusions though, I feel that the Props are somewhat testing this in the overhaul of the RV7000 (mk2). I can drop anyone of my wav.files on it and it will process it. Now i know that it is a native device and the issues are about Rack Extensions and the Sdk.
But since this is a ".3"- update, we might see things like sample loading in future ".0"- releases!

Cheers, Andy

I suspect the RV7000 mkII is testing sample loading for RE too, but there's no direct confirmation of this.

Thinking of 'hacks' is nice, but as happened with MIDI-out, even if it's possible it probably wouldn't be allowed by Propellerheads.

I was considering this myself - after all, they did test the RE system with The Echo, Alligator and Pulveriser, which act as native devices while supposedly operating in the RE environment. It's not too far a stretch to theorize that this RV7000 upgrade is a step in that direction, and I hope so, it's about time.

And if it turns out that's the case, all this talk of a workaround becomes moot, which is fine by me.

[raymondh]

Consider that anyone with access to the SDK is bound by an NDA. So noone can really comment. And as you say yourself, if there is a workaround, and props would allow devs to use it, i think we would've probably allready seen this

Lets see what we can learn from repatch files. I think you'll see that what you are saying may be technically possible.

Know that Repatch files are formatted in XML. XML is a standard anyone can read without fancy programs. They are "humanly readable". As an example i chose this one from Shape by Lectric Panda because it contains a huge amount of unintelligable data.

Code: Select all

 Shape LFO Editor 410140303F603F0F3E3F3D6F3D1E3C4E3B7E3B2E3A5E3A0E393E386E381E374E367F36303560351134423374332532563208313A306C301E2F512F042E362D6A2D1D2C512C052B392A6D2A222957290C28422777272E2664261B25522509244123792332226B2224215E21182052200D1F481F041E401D7C1D391C771C341B731B311A711A30197019311872183417761738167B163F16031548150D1453141913601327126F12381201114B11151060102B0F770F440F110E5F0E2E0D7D0D4D0D1D0C6E0C400C120B650B390B0D0A620A380A0E0965093D0915086E08480822077D07590736071306710650062F060F0570055205340517047B045F0445042B041103790361034A0334031F030A027602630250023F022E021E020F0180017201650159014E01430139013001280120011A0114010F010A010701040102010101010101010201040107010A010F0114011A01200128013001390143014E0159016501720180020F021E022E023F025002630276030A031F0334034A036103790411042B0445045F047B0517053405520570060F062F06500671071307360759077D08220848086E0915093D09650A0E0A380A620B0D0B390B650C120C400C6E0D1D0D4D0D7D0E2E0E5F0F110F440F77102B10601115114B12011238126F1327136014191453150D15481603163F167B1738177618341872193119701A301A711B311B731C341C771D391D7C1E401F041F48200D20522118215E2224226B23322379244125092552261B2664272E27772842290C29572A222A6D2B392C052C512D1D2D6A2E362F042F51301E306C313A32083256332533743442351135603630367F374E381E386E393E3A0E3A5E3B2E3B7E3C4E3D1E3D6F3E3F3F0F3F6040304080415142214272434244124463453346034653472347734843491349634A334B024B514C214C704D3F4E0D4E5C4F2B4F795047511551635230527D534B541754645530557C56485714575F582A5875593F5A0A5A535B1D5B665C2F5C785D405E085E4F5F165F5D60236069612F61746239627D634164056448650A654D660E66506710675168116850690F694D6A0B6A496B066B426B7E6C396C746D2E6D686E216E5A6F126F496F807036706C71217156720A723D72707322735374047434746475137541756F761C76487674771F77497773781C7844786C79137939795F7A047A287A4B7A6E7B107B317B527B727C117C2F7C4D7C6A7D067D227D3C7D567D707E087E207E377E4D7E627E777F0B7F1E7F317F427F537F637F728001800F801C80288033803E80488051805980618067806D80728077807A807D807F808081018080807F807D807A80778072806D80678061805980518048803E80338028801C800F80017F727F637F537F427F317F1E7F0B7E777E627E4D7E377E207E087D707D567D3C7D227D067C6A7C4D7C2F7C117B727B527B317B107A6E7A4B7A287A04795F79397913786C7844781C77737749771F76747648761C756F75417513746474347404735373227270723D720A71567121706C70366F806F496F126E5A6E216D686D2E6C746C396B7E6B426B066A496A0B694D690F68506811675167106650660E654D650A644864056341627D62396174612F606960235F5D5F165E4F5E085D405C785C2F5B665B1D5A535A0A593F5875582A575F57145648557C553054645417534B527D52305163511550474F794F2B4E5C4E0D4D3F4C704C214B514B024A3349634913484347734723465346034533446344124342427242214151 

Audio files can be captured and represented in a string. So in theory you can put that kind of data in there. It can then be reinterpreted by a RE as audio data.
But we also have to consider the following. Even though the repatch file is humanly readable, we don't know if props has set any constraints on its content. Maybe they set a maximum length on the type "string". In which case you may not be able to load more then a few milliseconds of sample with it. So i think its either in the constraints set on this, or the fact that props simply doesn't allow the use repatches for sample loading.

[note] I'm just a part-time programmer and registered dev... so i may be completely off here..

Gosh! Off topic, but seeing this post brought back memories of typing in the hex codes for SpeedScript on my Commodore 64 many years ago. Those who remember typing in programs from computer magazines will remember pages looking like