my requests: 1) more FUN slots. giancarlo told me once that FUNs are processed even if they aren't used, which means more FUNS would use extra CPU even if they weren't used by a program. so couldn't there be a tag in the program like <extrafuns> 1 </extrafuns> that would only activate them if a program needed them? i think i could do some cool stuff with compressors such as program dependent behaviors, and more things with LFO related stuff if i had more FUNs to play around with.
2) for nebula to accept midi note on/off data, and maybe velocity, for use with the internal envelope generators. i've looked at those envelope generators, and tried to figure out ways to use them, but could not. to me they seem totally useless. if they could be triggered by midi note on/off data, it could open up a whole new world to nebula with use as an 'analog' synth filter for vsts. maybe the actual note could even be used to have some 'key following' action, with the amount adjustable by a separate control. of course, i don't think that the attack/release time, sustain, etc are able to be set to MIX controls, so that would have to be added as a possibility too.
3) LFO shape to be selectable via MIX control. i know this would be tricky, BUT my idea for a solution would be to plot the whole set of shapes in Nebula's internal -1 to +1 controller range (example- sine= -1, triangle= -.9, square= -.8, etc), and then create a few preset selections out of the whole set of shapes, and make a fun type that would quantize the output of <a> so that it could only ever be one of the chosen lfo shapes. to me, the sine+, square+ etc shapes are worthless because they are just modified sines, squares etc. so create a fun type that only allowed the output to be equal to the basic lfo shapes- sine, tri, square, ramp u/d, and random. then allow that to be what determines the lfo shape.
then the only problem would be that nebula's readout is only numbers and can't say 'sine' 'tri' etc. so that would have to be dealt with somehow too. but the LFO function is totally crippled due to not being able to select shapes. i think this is the kind of stuff that may give nebula new life, but not if it isn't made more workable.
if you could have a predelay control that offset when the kernels got played, it would, again, open up a whole other dimension/world for nebula. not only could you use it for reverb, but now potentially any sampled vector could be used as a delay, when combined with the feedback function that is already there in nebula. think about it, you could have a control for predelay on a tape program, and then have a feedback control, and then you'd have tape delay. and the tape programs are already there so it would just take a bit of messing around with the program settings to transform almost anything into a filtered/saturated delay. instantly, half of the existing nebula library could find new uses as cool delay effects.
i've had these ideas for ages, and others, but to me it seems like this kind of stuff could breathe new life into nebula. it needs to be opened up to a wider field. cpus have caught up, where it can now be used to some extent for special effects for production/sound design rather than solely as a mixing tool.
if you go into 'edit' then go the the 'fun' page, there are the funs. you have 8 of them you can use. they are for setting up formulas that a dev can use to customize things going on in the inner workings of a program. i've made a few things where i ended up using all 8, but had at least some ideas for other things i could maybe add to those programs which would require more funs.
it wouldn't be as immediately useful as the other requests, but it could allow for more really cool stuff if people actually dug in and started utilizing them more.
SWAN wrote: The delay setting for actual echo/delay is really cool
i agree it seems like this one should be easy. but it may actually be a little more tricky. to me, the predelay becomes a lot more useful if it can be used together with the already existing feedback control, to allow for pretty much any program to be used as a delay w/feedback. but, that would mean that the predelay would have to be included in the feedback loop. that could possibly lead to difficulties to implement it that way, but i don't know.
i would much rather have it work that way though, because i think a lot of pre-existing programs could be used as awesome delay effects then. but, if a predelay was added that was not included in nebulas internal feedback loop, it would still be useful at least for reverbs.
other request- the metering issue should be dealt with somehow. one problem is that different devs have different gain stage standards. but here's something i noticed that seems to be a root of problems also- ive been using the really nice looking homemaderack skins for a while now, and they have nice looking meters. but i think the problem is that they are designed to look like analog meters but act more like digital ones. on an analog meter you usually want to stay around 0db. on the input meter with this skin, 0db is = to 0dbfs digital. but if a dev used the -18dbfs=0dbvu standard while sampling, then the meter should have that 0db point much lower to reflect that. the point where the meter hits 0db should already be well into the red because for probably all or by far most neb programs, a sample at 0dbfs is the loudest one taken from the hardware, and it most likely was well above 0dbvu.
if you send a signal at full scale digital level of 0db into neb, the meter pegs at 0db, so you'd have to send an even louder signal in to get into the red. but 0 is optimal recording/output level in analog. in neb it's overloading. and it's 18dbfs over where 0dbvu was in the sampling if the standard was used.
i think maybe the most versatile solution would be to make it so that devs could calibrate that input meter themselves by padding it up or down, to suite whatever standard they sampled at.
this should be an easy thing to do, and it would shift responsibility for the input meter being largely worthless away from acustica and onto the devs. if acustica allowed devs to trim the level going into the input meter, for each program, then it would be entirely the dev's fault if that meter didn't work well.
the output meter probably should just be a strictly digital meter, with 0db being = 0dbfs. but for input it should resemble an analog meter going into the hardware...
other request- if/when another neb update happens, make the default config xmls set up for a max look ahead of at least 20ms, and a max timed equal to whatever the max freqd setting is. i shouldn't have to tell users of my stuff to change those to allow for something more than 1.5ms of look ahead. unless changing those has some other effect?
I remember in the early days how much and how fast the nebula platform moved...I sometimes worry now that Giancarlo has lost a bit of that passion for it...or even that it may not be around....I thought the nebula engine might get picked up for bigger things but it seems to have plateaued...
It would be great to see some of these things implemented...
SWAN wrote:I remember in the early days how much and how fast the nebula platform moved...I sometimes worry now that Giancarlo has lost a bit of that passion for it...or even that it may not be around....I thought the nebula engine might get picked up for bigger things but it seems to have plateaued...
It would be great to see some of these things implemented...
allow for a way to change program that changes everything except for the current position of the main controls. this way a dev can provide HQ programs, that the user could switch to before render, and not lose their control settings.