| OvenWerk1 | aleb: Sorry we kind of left you hanging. | 13:13 |
|---|---|---|
| OvenWerk1 | We do not have a nice list of things we people to work on... not that organized | 13:14 |
| OvenWerk1 | aleb: For the most part we have been each looking for things that bug us and fixing/improving them. | 13:15 |
| OvenWerk1 | aleb: zequence is starting to make things more organized and formal so our focus is more aligned. | 13:17 |
| OvenWerk1 | aleb: in general Studio is "workflow oriented". This has two main implications: | 13:18 |
| OvenWerk1 | first, we select applications so they fit into a defined workflow. So we try to have all the apps needed to do that workflow without flooding our menu with duplicate apps. | 13:19 |
| OvenWerk1 | second, we are looking at setting our menu(s) up so that these applications are easy to find in these workflows. We are also looking at utilities to make system setup for a workflow a "one click" operation. | 13:21 |
| OvenWerk1 | aleb: if you have been on the mailing list for a while, you will have seen some posts about the "blueprints" being changed. They are still being set up 14.10, but that would be the place to look for things we have already identified as things we wish to try and do. | 13:23 |
| OvenWerk1 | aleb: A few extra things: none of us are paid employees, so this is a hobby for any one of us... if we seem slow to answer it is just because we are busy with life (real job, family, etc.) or that the computer is just not our passion right now. | 13:28 |
| OvenWerk1 | aleb: so while there are "dead lines" for getting something done for a release... there is not really a dead line for getting something finished. Other life may come first. | 13:29 |
| zequence | aleb: Yeah, sorry for not answering you before. This next cycle will be a lot more organized than previous ones I've been involved in, I could better answer your question in a few days time | 13:31 |
| zequence | OvenWerk1: I just found something that makes categorization of packages a lot simpler | 13:32 |
| OvenWerk1 | ok | 13:32 |
| zequence | OvenWerk1: Have you heard of debtags? Not sure exactly how that works, yet, but Debian has done a lot of work on finetuning categorization7 | 13:32 |
| zequence | OvenWerk1: There are made up of debtags http://blends.debian.org/multimedia/tasks/ | 13:33 |
| zequence | To see a debtag, install debtags, then on any installed package, do: debtags show <package> | 13:33 |
| zequence | For amb-plugins, it is a line like this: Tag: implemented-in::c++, role::plugin, works-with::audio | 13:33 |
| zequence | OvenWerk1: btw, that link is for finding packages belonging to the pure blend of Debian multimedia. It's sort of like Ubuntu Studio, but without their own install image | 13:34 |
| OvenWerk1 | I kind of figgured. | 13:35 |
| OvenWerk1 | I would guess that those tags depend a lot on the developer? | 13:36 |
| zequence | They are done in Debian, so I would think not so much actually | 13:36 |
| OvenWerk1 | Or are the debian packagers adding too? | 13:36 |
| zequence | Yes | 13:36 |
| zequence | Not sure how it works yet. Just started reading about it here https://wiki.debian.org/Debtags | 13:37 |
| OvenWerk1 | One of the problems we have seen in the desktop catgories is each developer does things differently. | 13:37 |
| zequence | I remembered talking to this guy who was working on defining blends last debconf, and he showed this stuff about Debian multimedia. I had just not realized the core components of it all | 13:37 |
| OvenWerk1 | One of the other problems is that different tagging systems are appropriate for different workflows. | 13:38 |
| OvenWerk1 | but a rich set of tags could make that easier to deal with. | 13:39 |
| zequence | Exactly. debtags seems pretty well figured out, if you ask me | 13:39 |
| zequence | but.. the debtags when I look at them now don't always make sense | 13:42 |
| zequence | They would need to be worked at - something we could assist in | 13:42 |
| zequence | And I realize the debian multimedia-* packages aren't based on those after all | 13:43 |
| OvenWerk1 | With all the convergence in UI going on, I am seeing a few directions showing up. There is the desktop use for home/buisness use where the number of apps is reall quite small. The developer setup with many more apps, but well known so search based menuing works well. However there is a third group of people who want to do something, but who don't really know what it is or what the tools that might do that are, these people work best with the old | 13:48 |
| OvenWerk1 | Tags seem to be designed with "what to install" in mind. though there may be other uses. | 13:49 |
| zequence | I don't think the job of the menu is to showcase applications. | 13:49 |
| OvenWerk1 | That may be true... so maybe we need some thing else that does. | 13:50 |
| zequence | debtags can be used to create application lists, into a database, and use that database for all sorts of things | 13:50 |
| zequence | the installer could make use of them | 13:50 |
| OvenWerk1 | Yes | 13:50 |
| zequence | or even ubuntu-software-center (which maybe it already does) | 13:50 |
| OvenWerk1 | I had thought of that | 13:50 |
| zequence | The problem I guess is how to make it easy for people to browse for applications | 13:51 |
| zequence | Installed, or not | 13:51 |
| OvenWerk1 | The problem with doing things that way is that the tags are set up from a world wide POV. (world wide meaning all SW) | 13:52 |
| zequence | If an application finder of any kind can use those tags, searching will become easy, as long as the tags are intelligently made | 13:52 |
| zequence | I think it's up to us to define what the tags should be - us, and debian-multimedia | 13:52 |
| zequence | Don't think they have put a lot of work into that | 13:52 |
| OvenWerk1 | Being able to refine a search can be hard for some people to do. | 13:52 |
| zequence | I don't agree. There aren't that plenty of keywords that come to mind | 13:53 |
| zequence | Things like recording, mixing, plugins, midi, etc | 13:53 |
| OvenWerk1 | plugins for example will yield a large group of sw, much of it not useful. | 13:54 |
| zequence | And then, combining them | 13:54 |
| zequence | plugin + eq, for instance | 13:54 |
| zequence | I think these debtags are the best tool for this type of categorization so far. And, best of all, it's upstream | 13:55 |
| zequence | For us, anyway | 13:55 |
| OvenWerk1 | Yes, I agree it has the right setup. | 13:55 |
| OvenWerk1 | The tags are populated on a volunteer basis? | 13:57 |
| zequence | Seems like it, yes | 13:57 |
| OvenWerk1 | What state are they in right now? | 13:57 |
| zequence | I already began work on categorizing applications, for Ubuntu Studio. I think it would take a bit of work, but we could go through with that, and then update the debtags in Debian. | 13:57 |
| zequence | ..with the categories that we define (as closely in line with upstream as possible, only adding when needed) | 13:58 |
| OvenWerk1 | Ya, I would like to use upstream tags. | 13:58 |
| OvenWerk1 | I am not so worried about apps we ship so much as apps our users may wish to add. | 13:59 |
| OvenWerk1 | I see Studio as a working starting point that can do the workflows we set up, but realize that most users will need/want extra tools that I would like them to be able to find easily. (this is what the extra installer is for) | 14:00 |
| OvenWerk1 | So the head end of our installer is what needs the most work. The displaying and actuall installing is fine and can be changed or whatever. | 14:02 |
| zequence | Yes, I was considering creating ubuntustudio-<workflow>-all metas, but don't think that's the way to go. Searching and finding apps easily is what is needed. | 14:02 |
| OvenWerk1 | but the choosing of what to show the user is the big thing | 14:02 |
| OvenWerk1 | So far, I have just been making a list by hand. | 14:03 |
| zequence | Yeah, that won't work in the long run. We need to work against standard systems - otherwise we either get a maintenance problem, or scewed categorization since too few heads were involved | 14:04 |
| OvenWerk1 | But for future we would want to make the search terms by hand and let the app find the apps to display | 14:04 |
| OvenWerk1 | It may also make sense to display the search terms on the top in a tree or hierarchiac manner and let the user add to or modify it. | 14:05 |
| OvenWerk1 | While all of the sw installers have a method of searching... I have found them all to be obscure... unless you are used to CLI ways of doing things and knew regx well | 14:07 |
| OvenWerk1 | The word frustrating comes to mind. | 14:08 |
| OvenWerk1 | (google isn't any better by the way) | 14:10 |
| OvenWerk1 | zequence: So I guess what I am talking about is a search interface. | 14:11 |
| zequence | Tree view makes sense to me, with pre-defined categories. When searching for a keyword, if it is found in packages in many sub-categories they still get separated | 14:11 |
| zequence | Rosco2: Hi Ross. I saw your email. Haven't got to answering those yet | 14:12 |
| zequence | Rosco2: Just preparing a mail about what we have so far, and start discussions about what to do coming cycle | 14:13 |
| zequence | Rosco2: But, one thing that does come to mind is the debug build problem that falktx has talked about sometimes. | 14:14 |
| zequence | Rosco2: That would be a job for debian-multimedia though, which is where we should do most of our packaging work anyway | 14:14 |
| zequence | OvenWerk1: packages often belong to more than one category though, so it should show up in all it belongs to. A tree view could still work. | 14:18 |
| zequence | OvenWerk1: One thing that would be absolutely great to have is having the link to the homepage of each application. It's found in control files for packages usually, so not difficult to add. | 14:19 |
| zequence | Definitely the best source of information for an application IMO | 14:19 |
| OvenWerk1 | zequence: I would also like some kind of relevance feature... like when was the last time this package was updated? though cp probably hasn't changed much... | 14:20 |
| OvenWerk1 | Ya, USC has the homepage. | 14:20 |
| OvenWerk1 | In our case, we are just showing the first line of the description. perhaps hovering over description could show the whole description too. | 14:23 |
| zequence | There could be a side view with the full description | 14:24 |
| elfy | good afternoon | 14:24 |
| OvenWerk1 | good morning | 14:24 |
| zequence | But, it's also possible we could just help improve ubuntu-software-center instead, or another installer | 14:25 |
| zequence | Hi elfy | 14:25 |
| OvenWerk1 | A number of people remove USC as a first task after install. | 14:27 |
| zequence | That is really up to them | 14:31 |
| zequence | But, they probably get by fine with a terminal | 14:31 |
| OvenWerk1 | Yes, I am just saying building on top of USC may not be the best place. | 14:31 |
| elfy | others probably do what I do - leave USC installed, lose it from menu and install synaptic | 14:32 |
| OvenWerk1 | I do that. | 14:32 |
| OvenWerk1 | We have synaptic on the ISO though | 14:33 |
| elfy | 'we' don't - I'm just in here as an interested party :) | 14:33 |
| OvenWerk1 | I know :) | 14:34 |
| elfy | just making sure :p | 14:34 |
| OvenWerk1 | I follow the xubuntu dev on irc a bit. | 14:34 |
| elfy | I just saw you in there - I'm not very observant :) | 14:35 |
| OvenWerk1 | We base Studio on the xubuntu desktop roughly, so it is good to watch where it is going | 14:36 |
| elfy | yep - I'm kind of floating about with the aim of helping with QA for studio where I can | 14:37 |
| OvenWerk1 | debtags is not installed by default zequence | 14:49 |
| zequence | OvenWerk1: I'm aware. And, as I said before, I don't know yet how it all works | 14:50 |
| zequence | Just that we should make use of them | 14:50 |
| OvenWerk1 | Downloading a browser to look. | 14:51 |
| OvenWerk1 | searching for Audio LV2 plugin reverb gives only one package :P (mda-lv2) | 14:55 |
| OvenWerk1 | removing the search term "plugin" adds invada-studio-plugins-lv2. | 14:57 |
| Rosco2 | zequence: Happy to help with build problems, have made a note of falktx | 14:57 |
| OvenWerk1 | removing the search term "audio" adds ir.lv2 | 14:58 |
| Rosco2 | zequence, I got as far as listing all the packages with "debug" on. Only chased through 3 or 4. | 14:59 |
| zequence | Rosco2: If you like, you can ask falktx in #kxstudio, who probably has a good idea which packages are affected - and at the same time, you could ask him about any other problems that Debian packages may have (in his opinion) | 15:01 |
| zequence | He does his custom builds of many of the packages in his PPAs | 15:01 |
| OvenWerk1 | zequence: it seems to me that while we do ship ir, we do not ship any impulse files to go with it. Is there usch a package? | 15:02 |
| zequence | OvenWerk1: No idea | 15:02 |
| zequence | Aren't those created manually? | 15:03 |
| zequence | I haven't got around to explore IR yet | 15:03 |
| OvenWerk1 | There are sites that have files that work wih it. | 15:03 |
| Rosco2 | Being new - Easy way to find packages we care about? | 15:03 |
| OvenWerk1 | I don't know what the legal aspects would be to packaging these files. | 15:04 |
| zequence | Rosco2: We were just discussing categorization. You have the sections sound, video and graphics. I guess sound is the most interesting right now | 15:04 |
| zequence | Rosco2: There are debtags too, which I've found to be a great tool, but packages don't seem to have correct tags, and I don't yet know how to use them for efficient searching | 15:05 |
| zequence | Rosco2: Debian Multimedia Blend has these tasks http://blends.debian.org/multimedia/tasks/index | 15:06 |
| zequence | Rosco2: Then, of course, you have ubuntustudio-audio, ubuntustudio-audio-plugins, etc | 15:06 |
| zequence | Rosco2: The sound section in utopic http://packages.ubuntu.com/utopic/sound/ | 15:07 |
| OvenWerk1 | zequence: searching for the search term "reverb" in a package menager turns up more packages than searching with debtags. Tap-plugins is missing from debtags. | 15:13 |
| OvenWerk1 | So debtags plus may be the way to go. Work on getting debtags to "catch up" at the same time. | 15:14 |
| zequence | OvenWerk1: the package manager will search also in the description, but that is not always what you want though | 15:23 |
| zequence | I guess for searching it is fine, but not for browsing | 15:23 |
| zequence | In the case of reverb, that word will probably come up only when a reverb is involved. | 15:24 |
| Rosco2 | Yes talk of debtags got me searching through my email archives. There was a call for people to help with tagging. Just reread the wiki. | 15:24 |
| OvenWerk1 | I am thinking debian linian needs to check to at least see the package is listed in the debtags BD and sugest the dev/packager add it. | 15:26 |
| Rosco2 | Trouble is debtags are not in Debian Policy, so not checked by Lintian? | 15:33 |
| OvenWerk1 | Thats what I mean. | 15:36 |
| OvenWerk1 | Rosco2: right now we have an installer utility for SW that many people might use but we don't want to ship by default. | 15:37 |
| OvenWerk1 | We spec what sw it shows by hand on the CL. | 15:37 |
| OvenWerk1 | we would like to change that by using a search based term(s) instead | 15:37 |
| OvenWerk1 | However we would like to maintain the close relevance we have now. | 15:38 |
| Rosco2 | OvenWerk1, Thanks - just looked at ubuntustudio-installer & the meta packages zequence mentioned | 16:19 |
| Rosco2 | Now I am a little more clued up! | 16:20 |
| OvenWerk1 | Rosco2: One other thing to mention, is that this installer is also used for those who have some other Ubuntu flavour besides ubuntustudio (lubuntu, kubuntu or vanilla ubuntu) and wish to install the Studio apps in that. This is why I have trid to use a simple UI that should be in all packages or is at least small to add. Probably in the future that might be qt. tk is supposed to be the default ui for python, but some falvours don't ship it to kee | 16:32 |
| OvenWerk1 | In the end, a person that installs very many studio apps ends up with GTK, tk, qt and maybe the kde libs too. | 16:34 |
| Rosco2 | I made that mistake in my early days with one package :-) | 16:39 |
| Rosco2 | Thought I would submit bug to Debian PTS to ask that missing debtags are highlighted. | 16:51 |
| Rosco2 | But it has already been looked at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708772 | 16:52 |
| ubottu | Debian bug 708772 in qa.debian.org "improve the integration between debtags and the PTS" [Wishlist,Open] | 16:52 |
| zequence | I'm gonna try get people to help out with tagging multimedia applications this cycle. Need to find out more about how it works though | 16:53 |
| Rosco2 | https://wiki.debian.org/Debtags | 16:54 |
| zequence | Yep, haven't had the chance to read through it yet | 16:54 |
| zequence | doing kernel maintenance currently | 16:54 |
| Rosco2 | I haven't tried, but wiki says anyone can do it | 16:55 |
| zequence | Yes, it even seems one can do it directly using a web interface | 16:55 |
| zequence | But, not sure where tags are defined. And who holds the keys | 16:56 |
| zequence | Anyways, I'll be looking into that later | 16:56 |
| zequence | OvenWerk1: Just realized that installing extra packages from the menu only shows packages aside from those in our metas, be they installed or not | 17:18 |
| zequence | If only installing the menu, or as now with trusty, ubuntu studio without any of the recommends to the metas, the extra install option becomes a little peculiar, like it was missing most of the goods. Using the meta installer would of course fix that, but it would be better if the installer always compared to installed packages, or like synaptic, just showed installed packages as checked (and unchecking would uninstall) | 17:20 |
| zequence | In this case, it would also make sense to use tags or categories to populate installable applications, instead of adding them one by one | 17:23 |
| OvenWerk1 | zequence: Yup, that is true. It was designed when there was no choice but to install the whole meta or not. | 17:25 |
| OvenWerk1 | The whole selection process now needs to be redesigned | 17:26 |
| OvenWerk1 | Using the CL to list apps or even search may no longer work. I will have to think about it. I had wanted the app to be generic, but it seems that will not be possible. I think we will end up with a commandline config file That holds what each instance should show. It should be able to handle a mix of package names and search criteria. | 17:30 |
| OvenWerk1 | It probably needs a way to understand when a package is a meta or not. | 17:31 |
| OvenWerk1 | This will also keep the desktop file from getting messy | 17:31 |
| OvenWerk1 | It could still be generic using switches. -m meta package -c configfile etc. Packages could still be just listed as is so long as they are first. | 17:56 |
| OvenWerk1 | So a command line might be: | 17:57 |
| OvenWerk1 | installer package1 package2 -m metapackage1 metapackage2 -c configfile -s search terms | 17:58 |
| zequence | You don't think that makes it overly complicated, and still too custom for the exact situation you are designing it for? | 18:00 |
| zequence | One way to go would be to use a db, sort of like the debian package cache, but with categorization that we have determined, with the help of sections (such as sound, graphics, video), and debtags? | 18:01 |
| zequence | Then, let the installer show all packages, but with the ability to browser. | 18:03 |
| zequence | It's called ubuntustudio-installer, so it doesn't need to be more generic than that | 18:03 |
| zequence | browse* | 18:03 |
| OvenWerk1 | Parsing CL is not that hard as there are tools just for that. So building that in is not hard. Keeping a local DB sounds like it would require mainaining. | 18:03 |
| zequence | That is the work we need to do anyway, with debian tags | 18:04 |
| zequence | Until the tags are worked out upstream, one could use a static file. Also, one needs to work out how to use the tags with the installer, if wanting to build a cache from just the debian package db | 18:04 |
| OvenWerk1 | There are some kinds of packages we would never show like lib* or *-dev | 18:05 |
| zequence | tags take care of that too | 18:05 |
| zequence | One can use tags to both whitelist, and blacklist | 18:05 |
| OvenWerk1 | I think we need an app spec. | 18:08 |
| OvenWerk1 | I think we should break it up into features to work on first and then second. | 18:08 |
| OvenWerk1 | So we can start with enough features to use now and then add more as we go. | 18:09 |
| OvenWerk1 | So if we start where we are with an app list, the next thing is to list both installed and not with the installed marked. | 18:10 |
| OvenWerk1 | the next thing is to add meta expansion. | 18:10 |
| zequence | I'm working on how to discuss feature specs for this cycle. I think I will start one email subject for each project blueprint that seems relevant, trying to address the most important stuff | 18:11 |
| OvenWerk1 | Ok | 18:12 |
| zequence | This is what I've written down so far https://wiki.ubuntu.com/UbuntuStudio/UtopicUnicorn/WhiteBoardSpecs | 18:12 |
| zequence | Going to split that up into several emails | 18:12 |
| OvenWerk1 | My thought with the installer is to always have a working app and have steps in managable sizes so whoever is working on it keeos from giving up. | 18:13 |
| OvenWerk1 | I am trying to think longer term in other words because I know I sometimes take some time away. | 18:14 |
| OvenWerk1 | It would be nice if we could build directly on someone elses flavour. | 18:15 |
| OvenWerk1 | Like take xubuntu's seed set and just overlay our own. | 18:16 |
| OvenWerk1 | +1 for ubuntustudio-audio-minimal | 18:17 |
| OvenWerk1 | It should set up jack and the user for RT work auto matically. | 18:18 |
| OvenWerk1 | zequence: ^^ | 18:18 |
| zequence | OvenWerk1: I will try to address that in other ways. Either making rt-kit working with jack, or creating a new default group | 18:19 |
| zequence | For trusty, I still need to make ubuntustudio-controls administer realtime | 18:20 |
| zequence | Possibly, it will need to do that for utopic as well, if nothing else was done | 18:20 |
| OvenWerk1 | zequence: how it is done, I don't care, but it should just work without having the user do something. | 18:21 |
| zequence | Yes, agreed | 18:21 |
| zequence | OvenWerk1: Seems Xubuntu has a new project lead: ochosi | 18:25 |
| OvenWerk1 | zequence: Re: linux-rt part of this will be our grub setup. Our controls app should be able to set which kernel is default. | 18:26 |
| OvenWerk1 | I had heard they were changing. He should do well. | 18:26 |
| zequence | OvenWerk1: Added it to blueprints whiteboard, so I don't forget | 18:31 |
| OvenWerk1 | zequence: (from reading the BP on controls) using ms is fine, but internal audio like HDA needs 3 periods for lowest latency. Might be an idea to go in steps of frames and periods. 256/2-10.7ms 128/3-8ms 128/2-5.33ms 64/3-4ms (HDA lowest) 64/2-2.67ms (My HDA will not let jack start at 64/2) | 18:47 |
| zequence | OvenWerk1: Yes, I | 18:49 |
| zequence | 've considered that | 18:49 |
| zequence | Not sure how to do that in the best way | 18:50 |
| OvenWerk1 | zequence: so long as it is in spec the details can come later. | 18:56 |
| OvenWerk1 | It may be enough to set the user at 2periods or 3 and just change the frames. | 18:56 |
| zequence | OvenWerk1: I'm considering moving detailed specs into wiki pages from now on, and make workitems more hands on, and related to bugs | 18:57 |
| OvenWerk1 | That would be fine. | 18:57 |
| OvenWerk1 | Each project could have one feature request bug added as the work progresses if that helped. | 18:58 |
| zequence | Might be enough we just make a list of features on a wiki page we want to have, then implement them as best as we can | 18:59 |
| OvenWerk1 | That is where we should start certainly. change things if it looks like it would help. | 19:00 |
| zequence | OvenWerk1: Also, I'm going to make a point of making specs as clear as possible before week 9 or so, of this cycle, and then I will look through each one and approve them, before they are good to go | 19:01 |
| zequence | After that, we do as little specs as possible. Just work on what we have agreed on | 19:01 |
| zequence | Or fix new bugs that come along | 19:01 |
| OvenWerk1 | ok. | 19:01 |
| aleb | I subscribed to https://blueprints.launchpad.net/ubuntustudio-meta/+spec/ubuntustudio-video-u, this is what I'm interested in. Curious to see what the workflows will be. :) | 20:20 |
| OvenWerk1 | Ahh, aleb perhaps you can guide us in that. | 20:21 |
| zequence | aleb: You do any video production? | 20:21 |
| aleb | I'm only an amateur | 20:22 |
| zequence | I'd say all of us are, in the video area | 20:23 |
| OvenWerk1 | aleb: the workflow might be: import video -> reformate for editting -> edit video -> add sound -> render to final format -> add menuing for DVD -> print to DVD | 20:34 |
| OvenWerk1 | But I susspect it may be a lot more rigorous than that. | 20:35 |
| OvenWerk1 | We have no SW for story boarding for example. There are a number of administrative things that would normally happen before shooting any video. | 20:36 |
| OvenWerk1 | As an amateur, most of us would do these things in our head | 20:37 |
| OvenWerk1 | But writing them down first is better. Having a clear idea of what shots are needed can save a lot of time. | 20:38 |
| OvenWerk1 | Once the shooting is done, however, the video needs to be converted into a format that works well with whatever video editor is chosen. Some editors are very good at doing this internally. Some are not. Some offer the ability to have a script set to do this too. | 20:40 |
| OvenWerk1 | most of the editing will be done in one program. Effects will be added here too. On a simple project audio may be done within as well. | 20:42 |
| OvenWerk1 | on a more complex project the whole audio workflow for audio recordng may apply as well. | 20:42 |
| OvenWerk1 | The editor will normally render it to whatever video format(s) needed and so the video ends up as a file(s). | 20:44 |
| OvenWerk1 | then it has to be packaged. (printed to DVD or uploaded or whatever) For a DVD menus ned to be added with whatever art work. There may be art worl for the front of the DVD and case as well. | 20:45 |
| OvenWerk1 | aleb: probably the two most used workflows for video might be some one who videos events such as weddings and prints them to DVDs and someone who makes videos to upload to youtube... like instructionals. | 20:47 |
| OvenWerk1 | VJing might be another, but that would tend to be a one app workflow and depend on that app more than anything. | 20:48 |
| OvenWerk1 | Note: I have left a lot out. While I have worked Broadcast at one time (early 80s), TV and video making are not the same thing.... and I did everything with tape. | 20:50 |
| aleb | Are people still using DVDs? :) | 21:05 |
| OvenWerk1 | :) someone who is videoing a wedding will be printing DVDs | 21:06 |
| aleb | I imagine the list of needed shots could very well be written / sketched on paper. I wonder what pro software can be used for this. | 21:06 |
| OvenWerk1 | I don't know. I wish I could see a complete list of how someone like the "tube" project did things (Blender.org) | 21:07 |
| OvenWerk1 | http://urchn.org/ | 21:08 |
| OvenWerk1 | One thing they and some audio people use is git. It may be that we should be shipping that. | 21:09 |
| OvenWerk1 | One of the DAWs actually uses it for saves. | 21:10 |
| OvenWerk1 | http://urchn.org/post/managing-animation-pipelines has a long list of sw used in production. This is an animated film so there are some tools a recorded video production might not use. | 21:13 |
| OvenWerk1 | aleb: ^^^ | 21:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!