accumulated feedback

Sun Jul 06, 2014 10:46 pm

hi there

during my use of magic i gathered some feedback i'd like to share (i really like how the name enables puns :) "how did you do this?" - "with magic" ;) . it consists of small and big changes or additions. I'll add to this list when more comes up. the list conists of items that i think should be there or would be a good idea. i'll happily discuss the validity of them :).

- middle mouse button for panning: using the scroll wheel and bars can get a bit tedious.

- overall sound volume / responsiveness: i catch myselv adjusting the system volume to controle the overall responsiveness of things. would be nice to have something like a "master volume" or "master responsiveness" within magic.

- particle systems: either a completely new particle system that can use the existing geometries as origin, or modifying the starsystem in a way that allows for more flexibility (emit in only 1 axis, emit radially, emit from a point, not a plane, and so on) and other particles than polygons.

- possibility to arrange many objects more easily: i find myself placing several polygons in a very tedious way. practical would be some kind of placing system or array that can place n objects in a grid or matrix or any other imaginable way.

- control module bypassing via midi/other: being able to use midi inputs to turn on/off certain modules or to bypass them.

- control modifiers via midi/other

- connect nodes easier: selecting multiple nodes at once and set them as input/output of one other node

- replace nodes with copied other nodes

- glow/bloom: some kind of another glow effect than the radial blur. (i imagine this will be possible with the freeform effects?)

- vignetting

- namechange of scenes with doubleclick or other conform shortcuts (F2)

- presentation mode: a mode where choosing where selecting scenes in the scene-bar is not making magic switch to them. this could be useful for adjustments on-the-fly ("darn, the bass dependent visuals are not working at all, better increase their responsiveness quickly"). this could also be done via midi of course, when modifieres could be controlled via that.

- possibility to use png-sequences as movie clips (because png actually support an alpha channel) (also other-format sequences).

- not keeping everything in memory: as far as i get this, the amout of objects and videos and what ever you are able to accumulate, is limited to your graphics memory. i get that the advantage of this is, that you can mix every single thing together and switch instantly to every scene. the way i'm building scenes they are often dependent on each other because i use scenes to group things which is pretty nice. however it would still be nice if i could unload a scene and the subscenes it depends on, because i'm not using them anymore. that way i'll be able to get more memory back for other things. this thought crossed my mind when i imagine myself doing a multiple hour show. my 2gb of vram wont last long in that case, especially when using a lot of movie clips.
i would it imagine like this: beforehand i predefine groups of scene (another suggestion here would be to use some kind of additional hierarchy level, eg. scenes and subscenes) which i want to use and not use at a certain point, let's call them scenegroups 1, 2, 3 and 4. i also predefine that scenegroup 1 and 2 are loaded at the beginning. during the performance i fade to scenegroup 2 at some point. scenegroup 2 is completely independent from scenegroup 1, so i decide to unload scenegroup 1. now i have additional memory free and i choose to preload scene 3. once this is completed, i can start to fade from 2 to 3, and so on.

that's that so far, i'll add more as soon as they pop up. thanks for everything.

\\Edits:

- being able to multiply a mask with a video or image input. (as i'm creating content in blender it's pretty easy to create a seperate movie file (or image) that is only a b/w mask). that may be a less resource-intensive method than lumakey?

- If a value responds to an input or not also should be controllable via midi. That way you could enable reactivity to bass at a certain point for example.

- as the volume often changes a bit from song to song, the response rom reacting parts also vary (suddenly values are too weak or too strong. This can be countered by adjusting the system volume of the mic in or screwing with the modifiers on the fly. However it's tedious. I wondered if it's possible to make some kind of feature that "listenes" to the imput for a few seconds and then auto adjusts a scale modifier in a way that the range of incoming values is between 0 and 1 (or other prespecified values). This feature could also be toggled via midi and "listen" as long as that midi button is pressed.
blackdot
 
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: accumulated feedback

Sun Jul 13, 2014 2:24 pm

Cool, thanks so much! Very helpful. Here are some comments:

- Middle mouse button for panning: Good idea.

- Overall sound volume: One thing you can do is select multiple inputs and set the gain on them simultaneously. But, yes, it would be nice to have a master gain setting.

- Better particle system: Yes, definitely needed.

- Module for arranging objects: Great idea. I think this would be pretty easy to do.

- MIDI control of power/bypass and modifiers: Already on our to-do list. :)

- Copying/pasting/replacing/connecting improvements: Also on the to-do list.

- More effects: Our most important goal will be to get FFGL support working, because it will immediately add lots of effects; after that we'll add some new modules of our own.

- Presentation mode: This is in there already. You can edit a scene without displaying it by ctrl-clicking (Windows) or cmd-clicking (OSX) on the tab.

- Not keeping everything in memory: Yeah, my original assumption was that people would just load different projects for long shows, but I always knew that this might not be feasible if there were no breaks in the show. So there will definitely have to be a way to manage graphics memory better.

- Volume responsiveness: I tend to dislike anything "automatic" because it has the potential to do undesirable things. I think a better solution would be to allow the gain on each input to be adjusted by MIDI. What do you think?
Eric
Site Admin
 
Posts: 3037
Joined: Wed Apr 09, 2014 9:28 pm

Re: accumulated feedback

Mon Jul 14, 2014 11:53 pm

- Overall sound volume: One thing you can do is select multiple inputs and set the gain on them simultaneously.[...]

Ah didnt know that.

- Presentation mode: This is in there already. You can edit a scene without displaying it by ctrl-clicking (Windows) or cmd-clicking (OSX) on the tab.

Man I feel very stupid now :roll: . The trouble I had to copy all my sub-scenes into one :D .

- Not keeping everything in memory.

For the semi-amateur gig I did this weekend my 2gb of graphics memory was more than enough. I had too few scenes though. I used one scene with two movie inputs though to play one, and load the other, then fade between them using a virtual midi controller on the alpha and brightness channel of the top video. was pretty neat and i did not have to prepare 15 preloaded clips or so.

But maybe the same technique could be used to "switch" between sets of scenes? One could have a designated switcher-scene which is very simple and not dependant on any other scenes. while this switcher-scene is running, all the other scenes are unloaded and smashed out, and then another group of scene is loaded. dont know if this is technically possible, however when the new set of scenes is loaded, one could again start switching to them.

I also noticed that short video clips seem to be loaded into the graphics memory, however very big clips (like feature length movies) are not. where is the limit here and what are the advantages disadvantages?

- Volume responsiveness: I tend to dislike anything "automatic" because it has the potential to do undesirable things. I think a better solution would be to allow the gain on each input to be adjusted by MIDI. What do you think?

yes i agree. however in that case, the gain would also have to be able to go into the negatives. Also sometimes one maybe just wants to add gain just on a certain frequency part and not everything. however this could then also be solved via midicontrol over modifiers, which you wrote is on the todo-list.
blackdot
 
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: accumulated feedback

Tue Jul 15, 2014 3:36 pm

But maybe the same technique could be used to "switch" between sets of scenes? One could have a designated switcher-scene which is very simple and not dependant on any other scenes. while this switcher-scene is running, all the other scenes are unloaded and smashed out, and then another group of scene is loaded. dont know if this is technically possible, however when the new set of scenes is loaded, one could again start switching to them.


Yeah, I think something like that is possible. The only issue is, it does take a certain amount of time to load multiple scenes into graphics memory -- sometimes at least a second or more. So you wouldn't want to do it during a live gig. I'll have to think about how to make it seamless.

I also noticed that short video clips seem to be loaded into the graphics memory, however very big clips (like feature length movies) are not. where is the limit here and what are the advantages disadvantages?


Actually, all video clips are loaded into graphics memory, but only one frame at a time. So the amount of graphics memory used per video is dependent only upon the pixel dimensions of the frame.

yes i agree. however in that case, the gain would also have to be able to go into the negatives


Sure, that's definitely doable :).
Eric
Site Admin
 
Posts: 3037
Joined: Wed Apr 09, 2014 9:28 pm

Re: accumulated feedback

Tue Jul 15, 2014 6:48 pm

Eric wrote:Yeah, I think something like that is possible. The only issue is, it does take a certain amount of time to load multiple scenes into graphics memory -- sometimes at least a second or more. So you wouldn't want to do it during a live gig. I'll have to think about how to make it seamless.

Actually, all video clips are loaded into graphics memory, but only one frame at a time. So the amount of graphics memory used per video is dependent only upon the pixel dimensions of the frame.


- i meant that the "switcher" scene kept running with some content and would be the only one not to be unloaded. That way the audience doesnt notice a thing.

-that explains a lot. So for magic the only important thing is the resolution and neither bitrate nor compression because that happens on the cpu and has nothing to do with the vram? I assume this explaines also the frame rate drop i got with a full hd clip when randomly offsetting the start point and quickly "go to start". iirc these frames would be loaded from the disk right? Could loading them from the normal ram be an option because theyre much faster? Or would even putting the clips on the ssd suffice?

Thanks
blackdot
 
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: accumulated feedback

Tue Jul 15, 2014 7:08 pm

Even unloading graphics memory can take a little bit of time, and it can't be done in the background, so there might be a few dropped frames. That's really the main issue to be dealt with, because you don't want anything to interrupt the live show.

Yup, the video resolution is the only thing that matters in terms of VRAM. Everything else depends upon the CPU, the regular memory, and the hard drive. It's certainly possible to load an entire video into regular memory; not all videos will fit of course, but I can look into making it an option. However, an SSD (or similar) should definitely be fast enough.

When specifying a non-zero start time for a clip, the frame rate can drop if the start time is not a keyframe. This is because several frames may have to be decoded at once in order to fully build the image; otherwise you'll get glitchy garbage like this: http://www.donrelyea.com/readymade_glitch/full/DSC03624.jpg. This has to do with the way modern video codecs (like mp4) are written -- most frames are delta frames which only represent a change from the previous frame. But if you don't have the previous frame, there is nothing to change from. So you need to go back to the most recent full frame, which is called a keyframe. Then you decode all the frames up to the desired start time. For a full HD video, decoding several frames at once can use quite a bit of the CPU and hard drive, so that's why you get a drop in frame rate.

Hope that made sense :).
Eric
Site Admin
 
Posts: 3037
Joined: Wed Apr 09, 2014 9:28 pm

Re: accumulated feedback

Wed Jul 16, 2014 5:33 am

yes that made perfect sense, you actually answered several other things that i never really understood :). But in this case, it may be recommended to recode ones videos with as many keyframes as possible (or at least 'more' keyframes)? and maybe even recode them in a less "efficient" way, that results in a bigger file but needs less intensive decoding when used? like maybe mpeg-2 instead of h264? thus reducing the stress on the cpu?

concerning memory: wont that not be a problem in the near future? it's already rising 4, 8, 16 even 32gb in new desktop computers.
blackdot
 
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: accumulated feedback

Wed Jul 16, 2014 3:33 pm

Yup, encoding the video with more closely-spaced keyframes can reduce dropped frames when jumping to arbitrary start points. Or, as you mentioned, having less compression can shorten the decoding time. But, as you also mentioned, the tradeoff for these things is that the video file is larger, so it takes longer to read from disk. So you need a fast disk.

It's quite possible that there could be enough memory on most people's computers to hold an entire uncompressed video, but you also have to keep in mind that people will likely want to have multiple simultaneous videos if they are using a program like Magic. So you can't assume that they will always all fit in memory.
Eric
Site Admin
 
Posts: 3037
Joined: Wed Apr 09, 2014 9:28 pm

Re: accumulated feedback

Wed Nov 12, 2014 10:28 pm

when i saw your tutorial about using scenes in other scenes, i remembered a suggestion I had about this:

It would be useful if you could group scenes. That way you could seperate those scenes, which you use just as templates for others, and then those which you are actually going to use for your performance. Maybe even some kind of branch-like structure could be used? Dont know what would be most efficient here.
blackdot
 
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: accumulated feedback

Wed Nov 12, 2014 10:44 pm

Hmm, so maybe like in a web browser, where you can have multiple windows with multiple tabs per window?
Eric
Site Admin
 
Posts: 3037
Joined: Wed Apr 09, 2014 9:28 pm

Re: accumulated feedback

Sat Nov 15, 2014 10:24 pm

no, i meant branched as in a usual file browser. in this case horizontally.

i made two drawings to clarify. i hope they are self explanatory :) (open them in a new tab)

branch.png
branch.png (200.77 KiB) Viewed 4733 times


unfolding.png
unfolding.png (31.31 KiB) Viewed 4733 times
blackdot
 
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Re: accumulated feedback

Mon Nov 17, 2014 12:23 am

Ok, that's interesting. So would the subscenes be available to all other scenes? Or just the ones in the same scene group?
Eric
Site Admin
 
Posts: 3037
Joined: Wed Apr 09, 2014 9:28 pm

Re: accumulated feedback

Mon Nov 17, 2014 8:55 am

Uhm this would be open to what is the most useful i guess :). But i think one should be able to add subscene1 of scene1 to subscene1 of scene2 via the scene node.

In principal the same is already possible. Make two scenes, combine them in two other scenes. Im talking only about grouping/branching the tabs somehow in a second layer, so things are more clear.
blackdot
 
Posts: 528
Joined: Sun Jul 06, 2014 10:18 pm

Return to Feature Requests

© 2021 Color & Music, LLC • This web site is mobile-friendly