TAL-Drum

[stillshaded]

Was really close to pulling the trigger on this. It's really great. So many drum samplers feel so bloated and laggy (geist 2 jesus)..

But, I do really miss the ability to have macros. I use that a lot for my wacky idm drums. So I'll stick with geist 2 for now. Even though it's a love hate relationship.

[fladd]

Can someone explain to me how to

(1) save a drumset in a self-contained way, such that it can be shared with other users?

(2) save the drumset in the DAW project directory (e.g. in REAPER), such that when I move the DAW project directory (e.g. to another computer), the samples and the references to them are intact?

Good question. I'm interested in knowing the solution to this as well.

Both can be done in just a few steps.

I added a 'user' folder inside the TAL-Drum Factory folder but this could be any location on your machine, and under there are separate folders for Kits, and for Samples.

..\some_path\DC\
..\some_path\DC\Kits\
..\some_path\DC\Samples\<kit_name>\

I use the 'Copy Samples to Directory...' option for my library, although you could use 'Copy Samples to Preset Directory' but this gets messy IMO (see note 1 below).

So,

Create self-contained kits

1. Create a new kit, lets say it's an awesome CR8000 kit
2. Save the kit preset to "..\DC\Kits\CR8000.taldrum"
3. 'Copy Samples to Directory...' and save the samples to "..\DC\Samples\CR8000\" (first creating the CR8000 folder)
4. Save the kit again. The paths will be updated relative to the kit preset (I think this is the step you are missing)

<snippet from CR8000.taldrum>
<mapping path="..\Samples\CR8000\CR8000 Kick.wav" ... which is relative to my Kits folder

As long as you maintain the Kit presets to Samples folder structure, it should work on any computer. I can now zip and share my 'DC' folder and it's all self-contained. This is basically how the Factory library works.


DAW project localisation

1. Save the kit preset to the current project folder e.g. "..\some_path\My_Project\Drums\"
2. 'Copy Samples to Preset Directory' (see note 2 below)
3. Save the kit again to update the relative paths to the samples

Now the kit should move with the project (for Reaper at least, I can't speak for the portability of other DAW's projects)

Note 1 - To keep things neater, there's nothing to stop you creating a separate folder for each kit preset and then using 'Copy Samples to Preset Directory', but the extra folder means an extra double-click to get to the actual preset when browsing.

Note 2 - You don't need to create separate 'kit' and 'samples' folders in a DAW project as there may only be 1 or 2 kits used in each project, so mixing presets and samples in one folder isn't such a management problem.

Thank you for the detailed explanation. Unfortunately, it does not work for me. Resaving the project after moving the samples does not update the paths in the .taldrum file, and they remain absolute paths on my system. I am using version 1.0.0

[fladd]

Looking more into it, it appears that the path of the .taldrum file referenced within the .taldrum file itself (why???) is always an absolute path to the location where the .taldrum file was originally saved. This is also true for the factory demo drumset, which points to a path that does not even exist on my system. And while that is weird, it apparently does not affect whether the drumset works or not.
However, the paths of the samples referenced within the .taldrum file are always relative to a globally set path. However, this being a global setting means that if you set this to a project directory and start a new song, you need to remember to now set it to the new song's project directory. Otherwise all samples in the new song are referenced to the project directory of the old song. This is a very non-intuitive (and error prone) way to do this. The setting should either be per instance (and not global), or there should be a one-time way to reference samples relative to a user defined project (without that project folder being remembered by the plugin and being used in other songs/scenarios).

[pierb]

Was really close to pulling the trigger on this. It's really great. So many drum samplers feel so bloated and laggy (geist 2 jesus)..

But, I do really miss the ability to have macros. I use that a lot for my wacky idm drums. So I'll stick with geist 2 for now. Even though it's a love hate relationship.

Macros would be awesome. Or at least being able to modulate with CCs.

[Raddler1]

Has the option of a browser sample 'hot swap' feature been talked about?

[neverbeeninariot]

Looking more into it, it appears that the path of the .taldrum file referenced within the .taldrum file itself (why???) is always an absolute path to the location where the .taldrum file was originally saved. This is also true for the factory demo drumset, which points to a path that does not even exist on my system. And while that is weird, it apparently does not affect whether the drumset works or not.
However, the paths of the samples referenced within the .taldrum file are always relative to a globally set path. However, this being a global setting means that if you set this to a project directory and start a new song, you need to remember to now set it to the new song's project directory. Otherwise all samples in the new song are referenced to the project directory of the old song. This is a very non-intuitive (and error prone) way to do this. The setting should either be per instance (and not global), or there should be a one-time way to reference samples relative to a user defined project (without that project folder being remembered by the plugin and being used in other songs/scenarios).

I've been doing a bit of testing and can reproduce what you're experiencing.

TAL-Drum saves it's current state (i.e. the contents of any loaded .taldrum preset plus any changes) to the REAPER project file (as do all VSTs).

If you save a new empty REAPER project and look at the contents of the project file in a text editor, it contains just the basic project information. If you load a VST (TD for example), save the project then re-open the project file in the text editor, you will see large amounts of data related to the current state of the VST when the project was saved.

If you move the REAPER project then open it, the VST state that is loaded from the project file will reference the old location of the TD preset and samples and you'll get the 'Samples missing' error.

Obviously, this is not a problem when using presets and samples that are relative to a known location, but localising the TD preset and samples then moving them, breaks that relationship.

Workaround (which it appears you found already).
After you've moved the project and opened it from it's new location, clear the 'missing samples' error, browse (from TD) to the new location of the kit preset and load it, then save the preset and the project. A faff, I know...

I don't know if there's a solution that provides 100% move-it-and-just-work portability, given that the VST state is stored in the REAPER project file, but raise it with Patrick, he might know how to resolve it.

Also, you're right about the .taldrum reference inside the .taldrum file, it doesn't affect anything related to loading the actual preset, I'm not sure why it needs to be stored that way, just the name would do.

[neverbeeninariot]

Has the option of a browser sample 'hot swap' feature been talked about?

It's been talked about and requested. 'Preview' was added in the 0.9.85 beta

For future reference, the change log is here: https://tal-software.com/products/tal-drum (scroll down past the videos)

[neverbeeninariot]

Was really close to pulling the trigger on this. It's really great. So many drum samplers feel so bloated and laggy (geist 2 jesus)..

But, I do really miss the ability to have macros. I use that a lot for my wacky idm drums. So I'll stick with geist 2 for now. Even though it's a love hate relationship.

Macros would be awesome. Or at least being able to modulate with CCs.

Anything that can be selected as a target in the mod-matrix can be modulated with CC or automation (it would be nice if some more options were in there too though...)



Seems like cut-off can't be modulated by CC, only by automation, which seems a little strange...

[Raddler1]

Has the option of a browser sample 'hot swap' feature been talked about?

It's been talked about and requested. 'Preview' was added in the 0.9.85 beta

For future reference, the change log is here: https://tal-software.com/products/tal-drum (scroll down past the videos)

Thanks, but do you know if they will add a proper hot swap feature? Preview is nice and all, but as soon as I select a different pad, the preview button turns off. Would be nice if it could be locked, otherwise, we are always turning it back ON when selecting different pads.

[neverbeeninariot]

Has the option of a browser sample 'hot swap' feature been talked about?

It's been talked about and requested. 'Preview' was added in the 0.9.85 beta

For future reference, the change log is here: https://tal-software.com/products/tal-drum (scroll down past the videos)

Thanks, but do you know if they will add a proper hot swap feature? Preview is nice and all, but as soon as I select a different pad, the preview button turns off. Would be nice if it could be locked, otherwise, we are always turning it back ON when selecting different pads.

I've no idea, tbh. Drop a request to support, they're pretty responsive - you can contact them from the support link on the main site

[fladd]

Looking more into it, it appears that the path of the .taldrum file referenced within the .taldrum file itself (why???) is always an absolute path to the location where the .taldrum file was originally saved. This is also true for the factory demo drumset, which points to a path that does not even exist on my system. And while that is weird, it apparently does not affect whether the drumset works or not.
However, the paths of the samples referenced within the .taldrum file are always relative to a globally set path. However, this being a global setting means that if you set this to a project directory and start a new song, you need to remember to now set it to the new song's project directory. Otherwise all samples in the new song are referenced to the project directory of the old song. This is a very non-intuitive (and error prone) way to do this. The setting should either be per instance (and not global), or there should be a one-time way to reference samples relative to a user defined project (without that project folder being remembered by the plugin and being used in other songs/scenarios).

I've been doing a bit of testing and can reproduce what you're experiencing.

TAL-Drum saves it's current state (i.e. the contents of any loaded .taldrum preset plus any changes) to the REAPER project file (as do all VSTs).

If you save a new empty REAPER project and look at the contents of the project file in a text editor, it contains just the basic project information. If you load a VST (TD for example), save the project then re-open the project file in the text editor, you will see large amounts of data related to the current state of the VST when the project was saved.

If you move the REAPER project then open it, the VST state that is loaded from the project file will reference the old location of the TD preset and samples and you'll get the 'Samples missing' error.

Obviously, this is not a problem when using presets and samples that are relative to a known location, but localising the TD preset and samples then moving them, breaks that relationship.

Workaround (which it appears you found already).
After you've moved the project and opened it from it's new location, clear the 'missing samples' error, browse (from TD) to the new location of the kit preset and load it, then save the preset and the project. A faff, I know...

I don't know if there's a solution that provides 100% move-it-and-just-work portability, given that the VST state is stored in the REAPER project file, but raise it with Patrick, he might know how to resolve it.

Also, you're right about the .taldrum reference inside the .taldrum file, it doesn't affect anything related to loading the actual preset, I'm not sure why it needs to be stored that way, just the name would do.

I know from other samplers, that they can just automatically save the used samples in the project directory. Renoise Redux does this by default, and I remember that Short Circuit (version 1) did this as well, once you ticked an option called "save samples in project directory". I always found this very convenient, since I very rarely want to just reference to samples somewhere on my disk. This is especially true for drum samples, which are so short and even when using a full drumset are not really that large together (so they don't add that much redundancy on the system, when automatically copied to the project directory).

I really hope that this can still be implemented in TAL-Drum!

[cowudders]

that's so great. battery import would take it out of this world for me ..

[Crayonking]

Where is key tracking?

[NAD]

Where is key tracking?

How exactly would that work when there's one key per pad?

[logicfixbrowserplz]

Is it possible to drag and drop samples from the plugin browser into your DAW?