creating a modular environment in jitter


    Apr 01 2006 | 12:08 am
    hi all, i've been trying to create a modular environment for video work. with modular i mean: there will be a main patch with 2 channels 5 layers each you will be controlling the video output with the modules (little patches) you put in channels, layers etc.. (for example audio in, midi in, fft in, brcosa, downsample, blur etc..) i'm not sure how to go about doing the main patch that will house the modules. i would like to do something like ableton live, where you put the modules side by side.. lloopp and cooper are other examples of this strategy..(or modul 8) or is there something like this? it would be such a blessing to jitter users. (somewhere to start)
    basically how can i create a max patch that will house other patches? without editing the patch everytime you want to put a module.. you can think about it like a vst host.. any help will ve much appreciated thanks furkan

    • Apr 01 2006 | 12:34 am
      hi.
      I have a system like this in the works, for 3D and 2D videomixing. Unfortunately its not ready for beta, however someone HAS released a very nice, simply user extendible environment for video mixing : DBV)
      check it out:
      if you ask Satoshi Horii nicely, he'll probably give you the source (he was kind enough to do so for me ;)
      http://abstrakt.vade.info/?p=46 is my little 'review' of the app, which shows how to make modules, etc.
      As for general module development in the abstract check out bpatchers, the thispatcher object for scripting the creation of objects, and check the tutorials.
      I use thispatcher to dynamically create a whole 'row' of bpatchers that contain my modules, and then script patcher connects to each patchers input and output, and then use the offset message to move the main bpatcher around to 'show' the right module.
      max does this pretty well, but getting it to work so it doesnt force framedrops when you load/unload modules is where the trickery comes in (this is why I make my thispatcher script run at the main patch load, although im having some issues with slowdown during that process).
      feel free to ask more involved questions once you start building a prototype, many people have many different methodologies and systems to this.
      v a d e //
      www.vade.info abstrakt.vade.info
      I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE!
      You will not be saved by the Holy Ghost. You will not be saved by the God Plutonium.
      In fact, YOU WILL NOT BE SAVED!
    • Apr 01 2006 | 12:49 am
    • Apr 01 2006 | 12:57 am
      I've spent a fair amount of time playing with various methods of creating a modular environment for video mixing. I have sources, channels with multiple, chained effects, output compositions and some other specialty objects. I've used Bpatchers and scripting so as to allow a flexible set of combinations. However, I'm fairly frustrated with bpatcher. There are a number of performance issues with it, and it only seems to haphazardly achieve the results that most users are looking for to create these sort of systems. Instead of banging our heads against the wall with bpatcher, maybe someone should just start with a clean slate and create a new object that gets the job done better. I'd love some bastard hybrid of an UBUmenu, bpatcher and poly. Give the object a directory of bpatches and it would preload the, allow you to switch between them, and update the gui properly when you made a selection. Yes, this could be done with objects currently available... but theory vs. the ugly results I've ended up with are two different things. So that's my suggestion: B-poly-ubu-GUI-menu-module
    • Apr 01 2006 | 1:11 am
      you know, I hear a lot of people complaining about bpatchers, but, from a strictly 'fps' as performance measurement, my patches run the same speed with or without poly.
      the only hit I get performance wise is how long the app takes to load initially.
      have other people seen bpatcher cause actual framerate drops?
      v a d e //
      www.vade.info abstrakt.vade.info
      I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE!
      You will not be saved by the Holy Ghost. You will not be saved by the God Plutonium.
      In fact, YOU WILL NOT BE SAVED!
    • Apr 01 2006 | 1:18 am
      ugh, by poly I meant bpatcher. Sorry, its been a long day - and I dont mean add useless posts to the thread. *sigh*
      v a d e //
      www.vade.info abstrakt.vade.info
    • Apr 01 2006 | 6:53 am
      I haven't gotten to the point where I'm considering Bpatchers effect on framerate. I'm just experiencing trouble with inconsistent behaviour, mostly with refreshing the GUI. The individual elements usually work, just get enough going (for example a big patch with lots of modules) and things start to break down. I'm on XP as well, so that doesn't help matters any.
      For example, right now I have a patch with two identical effects chain stacks. They should be differentiated by labeling, but in all other aspects the same. For whatever reason the second stack just doesn't work as effectively as the first. I have commands get lost in the shuffle when scripting, bpatchers not visually updating, etc. Too much going onscreen? Probably. Still, a simpler object to achieve the same end would eliminate some of the confusion.
      And if anyone wants to go digging, I posted an example patch of funky bpatcher behaviour a while ago. So from my perspective Bpatcher is a problematic object that doesn't even do what I'd really like it to in the first place. Apologies for ranting, but I've got a love/hate relationship with this object.
    • Apr 01 2006 | 5:18 pm
      Yeah, bpatcher isnt doublebuffered (if I remember from one of Jeremy's old emails to the list he mentioned that), but that will be fixed iirc (I cant speak for cycling, but I also recall mentions of a double buffered bpatcher for v 5 or somesuch).
      Anyhow, I also have some of those graphical glitches. (modules being drawn over by other modules), but you can force a redraw if you send a 'refresh' message to thispatcher. Might cause a slight CPU spike, but it cleans things right up.
      as for the inconsistent behaviour, I was also experiencing that, until I took some advice and started using scripting, a hidden object named 'origin' or something of the like, and started positioning my scripted objects with offsetfrom . Once i did that, it was like a whole new world or good behaviour (but im not sure if thats was your issue).
      v a d e //
      www.vade.info abstrakt.vade.info
    • Apr 05 2006 | 7:23 am
      thank you all very much, the dbv solution is exactly what i was looking for i dove right in the scripting tutorials i'll post if i come up with anything exciting
      furkan