Full Noise Library

It's been said that the current complement of noises is enough to do whatever you want...but I beg to differ with that... I've used FF alot for several years since the first Beta trial...and there are alot of things that just can't be made using the existing noise components... You can come up with elaborate constructions to try to get close to what you want...but the current noise "limitations" make it a far cry from what you really want...

IMHO, a program such as this should have a full library of all available noise known to mankind...authors should not have to create work-arounds to try to get close to common noise patterns...and beginners should have them all right out of the gate with this program...

*cough* In addition to that...a noise generator component with user-defined formula input would be soooooooo sweet with this program!!!

Hey Jitspoe, my primary reasoning is to make FF easier to construct filters without all the work-arounds and scripting... FF's learning curve for filter construction is too high and "assumes" too much beyond the average Jo user...

It's not only about making it easy for authors...which I think would be a big consideration in doing this given that the vast majority of filter submissions are at the introductory level... It's also about filling in the all the holes in the library where alot of common pattern filters are missing...remedying the use of work-arounds and scripts that make filters ten times slower than they should be...and making the program more user-friendly in filter construction...

Quote
uberzev wrote: why does GMM never respond to my feature requests?

Because the StevieJ's one is easier to reject
Just kidding. In fact, it is Vladimir who considers what features to implement. He does read this forum but hardly finds time to reply.

Excusy??? Have it set to StevieJ auto-reject again???

All the simple noises...and there's quite a few...just so beginners would not have to learn more advanced skills and/or scripting in order to get them...

BTW, quotes aren't working here...

Still can't quote...musta lost my quote privileges again... ...

Could do tutorials...but since we're talking about beginners, most wouldn't understand/comprehend what they are actually doing in following the tutorials...

It just seems "appropriate" that a program like this, that is centered on using noise patterns, would have the quintessential library of them for use... Just having the current ones seems very self-limitting, IMHO...

Quote
Kraellin wrote:(oh, and noises, too)

Maybe FF could play a "D'oh!" sample each time there is Lua errors.

But yeah, usually i blend noises and use layer modes etc to create variations but it would nice to have more available so this gets my +1 vote also.

Quote
StevieJ wrote: Take something as simple as a zig-zag noise pattern...

+1 !! i think we need the custom formula editor like StevieJ said. then vlad wont have to worry about what noises we want and (in the essence of FF) have us create our own. I also suck at scripting and dont want to spend the time to script. so having us only put in the formula (which I can do!) would work perfectly!

StevieJ, any imaginable noise can be made with Lua (correct me if I'm wrong). Do you really want to divert the developers' attention to a task that can be accomplished by the community?

@GMM: With Lua scripting still severely broken on Mac OS X, yes.

Quote
StevieJ wrote: there being no author copyright protection on straight texture results (allowing anyone to hyjack them fr om here even without having the program)

I saw SolarGen being used in a couple of places. I don't mind.

Quote
StevieJ wrote: [...] they are not submitting them due to the lack of incentives to do so

Precisely.

Still, I don't think that a noise library should be based on library filters, as that would be pretty incovenient to use during filter construction.

Instead, a convenient noise library should be based on...

1) component grouping functionality to organize components into functional groups, as has been requested for a long time. (aka "recipes", "micro-snippets", "sub-routines" or whatever you'd like to call it).

2) a dedicated Filter Editor panel that would allow for sorting/categorizing/filtering/annotating these component groups, and provide drag-and-dr op functionality for conveniently adding them to a filter tree.

Most likely, a full noise library would develop as a by-product of a full-featured "component group preset" system.

Quote
Kraellin wrote: rather than having a ton of different noise components, why not simply add more functions to the ones we have that would allow them to be other types of noise?

Let's make a distinction here between Noise components and "noise(s)":

We already have all the Noise components we need (and I disagree with StevieJ's basic premise that we need more). All kinds of "noises" can be built using the available Noise components in conjunction with blends, offsets, noise distortions and clever input-remapping. You could even use script to make your very own custom Noise component.

I've constructed tons of experimental "noise" recipes back in the FF 1.0 phase, and quite a few of these ended up being turned into full-fledged library filters.

However, sometimes you don't have the time to turn a promosing "noise" into a working filter, you just want to provide the "raw noise recipe", which only consists of the most basic filter tree setup.

Sharing these "raw noise recipes" currently is rather clunky. Sure, you could build a snippet (and I've tried this approach with the "Noise Lab" snippets), but these still need to function like normal library filters, and you need to dedicate time to test and properly document them.

The conclusion: We need a simpler way to share "raw noise recipes", and that's were the "component grouping" system comes into play (mentioned in my last post). It would not be a part of the filter library but instead be an online repository of "raw recipes" only accessible from inside the filter editor.

This repository would include a "full noise library" (with hundreds of community supplied "noise presets"), and it would also integrate the "raw recipes" that we currently share via snippets.

Quote
Kraellin wrote: but i do now take your point

I'm glad to read that.

Quote
Kraellin wrote: you want to access the internet fr om within the editor? i think that's a bad idea.

Well, we need some way to synchronize the "recipe" repository online, do we not?

Wha???

I think FF should just keep it as simple as possible for users as well as themselves by just loading up the "Noise" component catagory with all the different noise components... I don't think it really matters how many different noise components are in there...just so long as it makes it easier for beginners to create filters without having to learn all the more advanced component manipulation and Lua...

FF has stated that they do not want to put their resources into creating/purchasing all the additional noise due to the vast majority of customers being straight filter users...and everything can be created from either manipulating existing noise or Lua... I find this reasoning to be severely flawed at best...for several reasons that I've already stated...

Quote

Vladimir Golovin wrote elsewhere: Grouping is on high-priority on our list, but it won't be included into FF3.0. However, FF3.0 will contain (actually already contains) many infrastructural improvements that will pave the way for full-blown grouping in future releases (hopefully FF4.0). Under full-blown grouping I mean the ability to "build" your own components with custom inputs from Filter Forge's stock components, not just boxing and naming them.

[My emphasis]

There we have the foundation for our "full noise library", guys.

Indeed the question is: How do we store, share and access "custom components" both as creators and users?

IMO, storing/sharing/accessing Custom components should work identical to the way we work with filters, with a few key differences:

[*] Custom components should be usable fr om within the Filter Editor only, in the same way as Filters are usable only from the Main UI.

[*] Much like the filter browser in the main UI, we need some sort of Custom component browser panel within the Filter Editor, which allows for a drag-and-drop workflow. This browser would also provide filtering/sorting/categorizing as well as submit-to-library functionality.

[*] The current Component Bar could be revised/expanded to include the above mentioned Custom component browser functionality and thus provide a unified GUI area from which any and all possible stock components can be retrieved.

[*] Among the many categories in the Custom components browser, there would be the category "Noise", which is wh ere the "full noise library" would be located.

[*] Downloading Custom components from the online library should work identical to filter downloading via the website, you'd just be browsing a new library category. Downloaded Custom components would not be visible in the main UI filter browser, but only inside the Filter Editor's Custom component browser panel.

[*] The submission and editorial/review processes for Custom components could be the same as for regular filters, with the difference that Custom components would be submitted from within the Filter Editor.

[*] There should be a highly visible "Officially endorsed" tag (similar to Editor's Picks) given by the FF review staff to those Custom components that represent optimal solutions. These should also be given top priority in library searches.

[*] Over time, the legacy 'snippet' category in the Filter Library should be obsoleted. The best and most optimal snippets should be translated into Custom components by the community

[*] It should now be obvious that a "full-featured" Custom component system that includes an online repository is at least in part dependant on a redesign/expansion of the current Filter Library infrastructure, so I'm expecting these two systems to come to fruition in tandem, hopefully during the FF4.0 development cycle.

Don't do it, Dilla!!! ... lol...

Actually Dilla, you posted a link/pic of all the other available noise patterns a few years ago in one of the strings...just too lazy to dig through all of it to find it... It went from simple patterns like zig-zag to more complex organic patterns to create things like reralistic lightning, tree roots/branching etc... There are alot of them...with Worley being just a small part of it...

I'm not sure, buit I think there is copyright issues associated with different noise patterns...think FF paid for the Worley noise...so maybe they do not want to pay for any more of them...but I think that they should... It makes perfect sense for programs like this and Genetica to have them all...

Just look at the different filter constructions to try and emulate things like lightning, trees, zig-zags, and myriad other patterns...all advanced authoring skills needed to achieve with component manipulation and/or Lua... With FF not offering skilled authors further incentives to submit works like that anymore...and the library being literally burried in endless clone variants of the same filter by a predominantly beginner community...it just makes sense to me that expanding noise pattern library would allow the beginner community to expand the usefulness, quality, and range of submitted filters beyond the ongoing "slump" without needing to aquire all the advanced authoring skills... Let's face it...once most authors achieve these advanced authoring skills with components and Lua, they are not going to give away their hard/unique work to FF when they can better benefit from it by keeping and using it themselves...

Just gotta do the math...spending hours upon hours creating unique, useful filters to compete with 8000 other filters...in the hope of getting three of them to go 'High Usage for three reward ponts...all for a $150 program...

So in conclusion... More noise!!! lol...

you both make good points, so my question becomes what's the added overhead in compute time in making a 'group' type noise and one that IS a component? and would there even be any increase in that overhead or might it actually work the other way around with the group being the less costly?

inquiring minds want to know!

it wouldnt surprise me, dilla

What would be great is the grouping suggested with a custom user library tab with folders and sub folders. Then when you make a nice noise etc or find one in a filter you can just group it and drag and drop it into a user library folder ready to re-use at any time in the future.

I find with noises i can use blending to make many different types so if you were using custom groups or scripts in another group the options would be endless really. Of course it would be great to have new or additional options on the main noise types but i agree that grouping and a drag-drop user library is definitely the way to go.

Quote
Crapadilla wrote: That post is from May 2006. I'm smelling all my custom component dreams come true.

hehe