cymk

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..

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


creating-a-modular-environment-in-jitter

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)

http://dbv.gabocoy.com/archives/cat_download.php

if you ask Satoshi Horii nicely, he'll probably give you the source 

As for general module development in the abstract check out 

bpatchers, the thispatcher object for scripting the creation of 

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 

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I 

You will not be saved by the Holy Ghost. You will not be saved by the 

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)

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.

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.

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.

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


you know, I hear a lot of people complaining about bpatchers, but, 

from a strictly 'fps' as performance measurement, my patches run the 

the only hit I get performance wise is how long the app takes to load 

have other people seen bpatcher cause actual framerate drops?

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.

ugh, by poly I meant bpatcher. Sorry, its been a long day - and I 

dont mean add useless posts to the thread. *sigh*

ugh, by poly I meant bpatcher. Sorry, its been a long day - and I  
dont mean add useless posts to the thread. *sigh*

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.

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.


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, 

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 

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).

the dbv solution is exactly what i was looking for 

i'll post if i come up with anything exciting

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 

creating a modular environment in jitter