The library structure may lead to strong redundancy

Share your experience, tips & tricks, show off your music. Wishes, ideas and feature suggestions
Post Reply
teacue
Posts: 50
Joined: Wed May 30, 2007 9:20 am

The library structure may lead to strong redundancy

Post by teacue » Wed Sep 14, 2016 2:52 pm

Working quite a lot with PunchBOX I really love the sound and the features of your plug.
In the meantime I use it not only for BD but also for SN, HH and CL and it works really good :)

But ... and it is quite a big but!
You definitively know how important it is to be able to quickly browse through the sample library and how it is essential to quickly load samples in order to test how you want to layer the samples.
This is why you took care to create a very nice browser.
But to me the library structure of your browser has a big downside: the fact that each module has its own library.

I am sure that there are important reasons why you did this but you are surely aware that to be able to have acces to all samples in each module in order to be able to create any kind of layering it is necessary to copy all the samples in each module library!
It means you get a 4 times redundant sample library!
In fact this is 5 times because your system has to import first from the original!

As I previously said I now use PunchBOX also for SN, HH and CL, you can them imagine that at some point it begins to be a quite huge library!
Of course I am aware that today space place is not a too big problem as it once was but I think it should not be necessary to have 5 times the same library.

Is there any chance that you reconsider this structure?

Another point is that you once explained that it is not possible to create user folder.
It would be great and would help a lot if you would allow to create user folder inside of the user library!

Best regards

hesnotthemessiah
Posts: 12
Joined: Tue Feb 04, 2014 5:34 pm

Re: The library structure may lead to strong redundancy

Post by hesnotthemessiah » Mon Oct 10, 2016 10:10 pm

I have to agree. I prefer to not think of the additional sample modules as "Click", "Tops" and "Tools" - I look for the type of sound I want and, in the process may find a sample that fits just nice with my kick for that track - I don't care if it is a "Click", "Tops" or "Tools". If it fits, it fits! So, I think it would be much better to trash the names of these three sample modules and allow the user to load from the same folder of samples which could be subdivided by the user into whatever categories they desired - perhaps they might want "Click", "Tops" or "Tools" so they can create these subfolders and then put whatever samples they want into these subfolders. That would suit everyone then. :P

User avatar
Sebastian@d16
Posts: 1524
Joined: Tue Nov 07, 2006 9:20 pm
Location: Katowice/Poland

Re: The library structure may lead to strong redundancy

Post by Sebastian@d16 » Wed Oct 12, 2016 10:44 am

Hi guys,

Thank you for response and feedback. With PunchBox we provide not only an instrument, plug-in but also a "template" for creating Kick sounds, the structure (of four generators with a purpose for each one) which is conceived implicitly for producing Kick sounds. I'm aware PunchBox can be used in many different contexts and ways, not always as kick generating machine and that leads that the approach we've taken not always fits the users' needs. Splitting the content to 4 generators and keeping it separated was a conscious action from our part because it was a results of how the factory bank (presets / samples) was created by guys from Resonance Sounds and it reflects their line of work to some extent. It's not only the content that's been provided to the users but also workflow for making creation of kick sounds more efficient. For us importing user samples is just sort of icing on the cake, addition, to make possible to users to import they own sound source into the PunchBox. We don't want to change a lot in this matter, and speaking of keeping the content split for all generators we rather are going to keep it that way.

However ...

It's been suggested to us that the process of importing the samples and storing user samples itself is not very efficient. In the current version of PunchBox samples are kept in our own format to make loading, tagging, processing faster and when PunchBox is used in a DAW the samples are stored within the project as references. That can lead to some very confusing situations; like when you rename the sample in User resource, which could be used in one of your projects, after renaming the sample the project file utilizing the sample (in PunchBox) won't find the sample, because the NAME is the reference for it. So a project file doesn't aggregate the samples themselves, but references only. It's quite good approach for Factory content which can't be edited, but not for User content apparently. And we want to make some adjustments in this area and samples will be kept along with the project (as binary PCM data). Additionally we'd like to introduce some sort of functionality to make possible "direct import". Ideally and in final form we'd like to have additional elements in the Resources list in the right area of the Sample Browser (Users, Factory). The elements would be short cuts to the locations on user's hard drive (paths) as alternative resources (added and maintained by user). This would make the process of importing way quicker, avoiding potentially dangerous situations (with samples missing when name's changed). So the samples wouldn't be imported, but listed and double-clicking an item would load / import it directly to the project.

This would kill two birds with one stone; no redundancy as you could just set the path to your sample folder in each browser (Body, Click, Tools, Tops) and name references wouldn't be used anylonger.

That's our response to your feedback,

What do you think?

Thank you,

Kind regards,
Sebastian

hesnotthemessiah
Posts: 12
Joined: Tue Feb 04, 2014 5:34 pm

Re: The library structure may lead to strong redundancy

Post by hesnotthemessiah » Wed Oct 12, 2016 9:06 pm

EDITED
Sebastian@d16 wrote:. And we want to make some adjustments in this area and samples will be kept along with the project (as binary PCM data). Additionally we'd like to introduce some sort of functionality to make possible "direct import". Ideally and in final form we'd like to have additional elements in the Resources list in the right area of the Sample Browser (Users, Factory). The elements would be short cuts to the locations on user's hard drive (paths) as alternative resources (added and maintained by user). This would make the process of importing way quicker, avoiding potentially dangerous situations (with samples missing when name's changed). So the samples wouldn't be imported, but listed and double-clicking an item would load / import it directly to the project.
Brilliant!! :D I think you have got it all covered there.

1)Ideally I would like to be able to load a sample from anywhere on my hard drive.

2)Chose your sample storage folder for user samples. This is set manually by the user for each instance of PunchBOX. This information is saved as part of the project so that, when the project is reloading, it will look in the folder that you had chosen for each instance of PunchBOX to store it's user samples. If the user decides to use this user sample storage method then a message could appear to remind them to set a sample storage folder for each instance of PunchBOX when they first load a user sample into it. No chance of misplacing/renaming/editing/etc. the sample at a later date and then losing it when you reload that project.

Actually, I have just realised that it is quite quick and easy to do all this myself just using the standard copy and paste of samples within Windows. Problem is, in the euphoria of creating my latest banger of a track, I will never remember to do such a sensible thing!

3)"BROWSE" within a generator to load a sample from any of my sample folders and then use the "PREV" and "NEXT" buttons on the generator to then skip back and forth from the point where the sample originates. This would allow me to edit the generator settings as I skip through the sample's folder. I really want to be able to edit the generator settings whilst auditioning samples - I often might adjust the decay or volume so that I can hear if it's what I want and then skip quickly to the next sample. This is possible using the built in samples but not if you are loading your own samples.

It's really great to see developers taking note of, and responding so well to users' requests. I could go on and on about how much I love PunchBOX and how great it was using it last night in a new track where I used automation on quite a few of it's parameters to fade it into the track and how the automation of certain parameters really helped alter the tone of the kick that really worked so well with the track. But I won't.

teacue
Posts: 50
Joined: Wed May 30, 2007 9:20 am

Re: The library structure may lead to strong redundancy

Post by teacue » Fri Oct 14, 2016 9:11 am

Hi Sebastian,

great that you finally answer ;-)

Your "Direct Import" idea sounds good to me and indeed it seems it would make the possible redundancy I mentioned, disappear.
I was not aware of the possible problem you mention with Name Changing of a sample because I assumed the whole sample itself was imported in your data bank and not only a reference. But your solution would solve this too.

"Additional elements in the Resources list in the right area of the Sample Browser (Users, Factory)" seems to be a good solution, I just hope it will allow to create subfolder and not only a big User folder.
In my opinion an efficient handling of samples needs the possibility to catalog them with as much subfolder as the user needs.
For example I do need my samples organised in different hierarchy.
Sometimes it can be in Category, but sometimes it can be in Brand Name or even in Projects.

For example:
Kicks / Brand Name 1 / House
Kicks / Brand Name 1 / Techno
Kicks / Brand Name 1 / Acoustic

Kicks / Brand Name 2 / House
Kicks / Brand Name 2 / World

Snare, Hats ... and so on

or
Brand Name 1 / Kicks / House
Brand Name 1 / Kicks / Techno

Anyway I am glad that you are open for suggestions.

BTW you write: "For us importing user samples is just sort of icing on the cake"
I hope you realize that it is much more than this and that this funtion is essential for a lot of users!
I am also not sure if I would have bought your Plug without the import possibility.

Best regards and thanks for your work

User avatar
Sebastian@d16
Posts: 1524
Joined: Tue Nov 07, 2006 9:20 pm
Location: Katowice/Poland

Re: The library structure may lead to strong redundancy

Post by Sebastian@d16 » Fri Oct 14, 2016 9:55 am

Hi Teacue,

My apologies for little delay, but preparations for Repeater release absorbed me :)
I assumed the whole sample itself was imported in your data bank and not only a reference
The samples are stored in our data bank, however when a sample is used in a preset, the preset keeps only name reference for the sample, not the sample itself.
seems to be a good solution, I just hope it will allow to create subfolder and not only a big User folder.
I suppose those symlinks to user folders (containing samples) would be sub-items for the User resource. It's just an idea right now, but we'll think it through once we start to work on PunchBox again.
BTW you write: "For us importing user samples is just sort of icing on the cake"
I hope you realize that it is much more than this and that this funtion is essential for a lot of users!
I am also not sure if I would have bought your Plug without the import possibility.
We see it now, I'm speaking more about the intentions we had when we were working on PunchBox. At some point we even assumed it should be more like a rompler / player with simpler interface (with lot of settings hidden before user), but we changed our mind and decided to give users complete freedom. Definitely user sample management should be different and more flexible.

Kind regards,
Sebastian

Post Reply