Re: [Gimp-user] MIDI controllers for controlling brush size and colors [was: Save Export Complaints]
Hi. I've not been on my Linux system with Gimp for a bit so Ideally I need to work through exactly how I set that up and how I'm using it. The aconnectgui is how to see and make the connections but in actual fact it's best to do that from command. The connection isn't remembered so rather than set it up via aconnectgui I just run a command every time I start Gimp. As for the colour adjustments. You turn knobs to change colours but you see that colour changing on the colour wheel and can still select there anyway, if you want. It can be used to make small colour changes as you paint or values, opacity, whatever you want. Brush size is an obvious one. You can literally change stuff as you paint a stroke but that can end up a bit glitchy. One problem with Gimp 2.8 is that the top size of the brush is far too big. If you compile from scratch you can change that. This needs to be mentioned in the Gimp developer list. It's also possible to have UI to set that largest size of brush so it's not too big. I've seen the code that needs added to do that. This all needs to be better sorted out to make Gimp more ideal for painting.These are simple changes that need to be in Gimp. Changing it and compiling is too much trouble. All the functions that can be mapped to keyboard can be mapped to MIDI except the MIDI has continuous controller meaning instead of one key command ton say make a brush bigger you have values from 0-127. Obviously this is better. I mentioned that with colour I think you need to set the controller to not go to value 0. I'll have to confirm that but I think value 0 for a colour causes it to turn all colours to 0 or something similar. There is some kind of problem with that. I think it needs to be 1-127. Maybe some other people can have a go with this. Any piece of modern music gear tends to have MIDI so if you've got any keyboard or whatever you can test this or use software that can send MIDI to test it. An example would be ZynAddSubFX. That should show up at ALSA and it should have some MIDI out function (I Think). This would obviously be useless but can used used just as a test. Until I get back into Gimp for painting again, I can't explain everything. On 12 September 2012 18:49, yahvuu yah...@gmail.com wrote: Hello Ryan, Am 12.09.2012 15:25, schrieb Ryan Stark: [..] Gimp can be hooked up to a MIDI controller for controlling brush sizes or anything else. This is a superb feature. You can buy a little MIDI controller with lots of knobs and sliders. VASTLY superior to sliders on graphics tablets. Und Am 12.09.2012 18:31, schrieb Ryan Stark: Now that's a really neat idea. What (affordable) MIDI controller do you like? I use a Korg NanoKontrol. The one here with the sliders and knobs: http://www.korg.co.uk/products/software_controllers/nano2/sc_nano2.php I'm not sure how much it is but it's cheap compared to what there used to be. It's very small and portable so ideal for Gimp. It communicates with alsa (via USB). You have a small GUI app called aconnectgui where you can see the Korg output and Gimp input. You just connect them up. I actually do it from command but that's because I couldn't find aconnectgui in the Arch repo. Here's some info from the Ubuntu site: https://apps.ubuntu.com/cat/applications/precise/aconnectgui/ One problem is that you need the Korg editor (Windows or OSX) to change MIDI functions on the NanoKontrol. That should work via wine but I didn't try that. The reason you have to change some things is that by default some of the switches are momentary or maybe that wasn't the problem. I can't remember exactly but I had to edit a few things. I'm not on Linux at the moment to look at it exactly but you'll find MIDI under Input controllers in Gimp. You have a vast choice of Gimp parameters and you set them by choosing the one you want then moving the appropriate knob on the controller to set it to the parameter. There is stacks you can do. I like to set it to change colours i.e. one knob will increase red etc. Selecting colours, values etc in the colour wheel suddenly starts to become obsolete. Actually, thinking about that particular function, I think that was why I had to edit the Korg via its OSX(or Windows) editor. I think you need that particular value to not go to zero value. Probably I should document all this somewhere properly. The huge advantage over a graphics tablet slider is that MIDI has continuous controllers. This means you move the knobs and sliders up and down to exact values. You are not sending a keyboard command. It's really quite ingenious whoever thought of adding that to Gimp and I bet hardly anyone uses it. even more so since this really interesting piece of information got buried in one of those threads i really cannot justify spending my time to wade through such slurry :) I'm really curious about the following passage: [..] I like to set it to change colours i.e. one knob will increase
Re: [Gimp-user] MIDI controllers for controlling brush size and colors [was: Save Export Complaints]
You can do anything. That's why it's so great. MIDI has continuous controllers and notes. Notes can be mapped as well. Continuous controllers can be set to any value or a button sends that value so say you want a collection of brush sizes, you set a button to send a value anywhere from 0-127 that can be used to set any brush size at the click of a button. On 13 September 2012 11:46, Ryan Stark efflux...@googlemail.com wrote: Yes, you could connect through Jack but Hardware will show up at ALSA so I don't think Jack would actually be a benefit for Gimp use but maybe you'd need this to test with software? ZynaddSubFX can connect via ALSA or Jack (or use Yoshimi) but can you then connect to GIMP somehow maybe via the Jack connection UI where ALSA and Jack MIDI show up? I'll have to leave this for others to test. I'm not on my Linux graphics machine at the moment. I'm on OSX. On 13 September 2012 11:36, Ryan Stark efflux...@googlemail.com wrote: There's a video on youtube of somebody doing it but I don't recommend pushing it this far i.e. changing as you actually make a stroke. That can get a bit glitchy. Also, a keyboard isn't ideal. You want something like that Korg. Before the Korg NanoKontrol, there wasn't anything as ideal but that machine is cheap, small and perfect for the job. http://www.youtube.com/watch?v=Llu3WGbJpzc On 13 September 2012 11:25, Ryan Stark efflux...@googlemail.com wrote: Hi. I've not been on my Linux system with Gimp for a bit so Ideally I need to work through exactly how I set that up and how I'm using it. The aconnectgui is how to see and make the connections but in actual fact it's best to do that from command. The connection isn't remembered so rather than set it up via aconnectgui I just run a command every time I start Gimp. As for the colour adjustments. You turn knobs to change colours but you see that colour changing on the colour wheel and can still select there anyway, if you want. It can be used to make small colour changes as you paint or values, opacity, whatever you want. Brush size is an obvious one. You can literally change stuff as you paint a stroke but that can end up a bit glitchy. One problem with Gimp 2.8 is that the top size of the brush is far too big. If you compile from scratch you can change that. This needs to be mentioned in the Gimp developer list. It's also possible to have UI to set that largest size of brush so it's not too big. I've seen the code that needs added to do that. This all needs to be better sorted out to make Gimp more ideal for painting.These are simple changes that need to be in Gimp. Changing it and compiling is too much trouble. All the functions that can be mapped to keyboard can be mapped to MIDI except the MIDI has continuous controller meaning instead of one key command ton say make a brush bigger you have values from 0-127. Obviously this is better. I mentioned that with colour I think you need to set the controller to not go to value 0. I'll have to confirm that but I think value 0 for a colour causes it to turn all colours to 0 or something similar. There is some kind of problem with that. I think it needs to be 1-127. Maybe some other people can have a go with this. Any piece of modern music gear tends to have MIDI so if you've got any keyboard or whatever you can test this or use software that can send MIDI to test it. An example would be ZynAddSubFX. That should show up at ALSA and it should have some MIDI out function (I Think). This would obviously be useless but can used used just as a test. Until I get back into Gimp for painting again, I can't explain everything. On 12 September 2012 18:49, yahvuu yah...@gmail.com wrote: Hello Ryan, Am 12.09.2012 15:25, schrieb Ryan Stark: [..] Gimp can be hooked up to a MIDI controller for controlling brush sizes or anything else. This is a superb feature. You can buy a little MIDI controller with lots of knobs and sliders. VASTLY superior to sliders on graphics tablets. Und Am 12.09.2012 18:31, schrieb Ryan Stark: Now that's a really neat idea. What (affordable) MIDI controller do you like? I use a Korg NanoKontrol. The one here with the sliders and knobs: http://www.korg.co.uk/products/software_controllers/nano2/sc_nano2.php I'm not sure how much it is but it's cheap compared to what there used to be. It's very small and portable so ideal for Gimp. It communicates with alsa (via USB). You have a small GUI app called aconnectgui where you can see the Korg output and Gimp input. You just connect them up. I actually do it from command but that's because I couldn't find aconnectgui in the Arch repo. Here's some info from the Ubuntu site: https://apps.ubuntu.com/cat/applications/precise/aconnectgui/ One problem is that you need the Korg editor (Windows or OSX) to change MIDI functions on the NanoKontrol. That should work via wine but I didn't try that. The reason you have to change some things
Re: [Gimp-user] MIDI controllers for controlling brush size and colors [was: Save Export Complaints]
You need to set up the Korg using Windows software to get it all exactly as you want. That should work in wine. Gimp will remember all the mappings but the one problem is that Gimp doesn't remember the connection so you have to connect the ALSA output of the MIDI controller to Gimp's input after starting Gimp. This isn't difficult though. It's simply the connection posts number and MIDI channels. One command can do that. That's a bit easier than opening the GUI to be honest. One benefit of using the MIDI controller to adjust colour is that you can create minor adjustments of colour constantly which helps with the fact that Gimp doesn't blend paint on the canvas. To be honest though, Photoshop didn't have that feature for ages and I didn't see it stopping great art in Photoshop. A lot of great Photoshop artists still generally don't use paint blending because they are so used to not having that feature in the past. It's a very over rated feature. It just seems very cool to begin with if you try in it Krita or Mypaint. If you can paint or draw, the lack of that feature is not going to stop you making great paintings. I have been building up a large collection of brushes in Gimp. The default ones were very poor. 2.8 is better but still, I don't think the full power of Gimps brushes is utilised by most people. I find that in Krita and especially Mypaint (although there is a great procedural aspect to the brushes in that app) you can't create as cool brushes as you can in Gimp. Gimp also understands Wacom pens that rotate. Another largely unknown feature (if you have a pen that sends rotate info). Gimp is really a seriously underrated app. Go check out any brilliant art done in Photoshop and Gimp can do all of that easily. On 13 September 2012 11:53, Ryan Stark efflux...@googlemail.com wrote: You can do anything. That's why it's so great. MIDI has continuous controllers and notes. Notes can be mapped as well. Continuous controllers can be set to any value or a button sends that value so say you want a collection of brush sizes, you set a button to send a value anywhere from 0-127 that can be used to set any brush size at the click of a button. On 13 September 2012 11:46, Ryan Stark efflux...@googlemail.com wrote: Yes, you could connect through Jack but Hardware will show up at ALSA so I don't think Jack would actually be a benefit for Gimp use but maybe you'd need this to test with software? ZynaddSubFX can connect via ALSA or Jack (or use Yoshimi) but can you then connect to GIMP somehow maybe via the Jack connection UI where ALSA and Jack MIDI show up? I'll have to leave this for others to test. I'm not on my Linux graphics machine at the moment. I'm on OSX. On 13 September 2012 11:36, Ryan Stark efflux...@googlemail.com wrote: There's a video on youtube of somebody doing it but I don't recommend pushing it this far i.e. changing as you actually make a stroke. That can get a bit glitchy. Also, a keyboard isn't ideal. You want something like that Korg. Before the Korg NanoKontrol, there wasn't anything as ideal but that machine is cheap, small and perfect for the job. http://www.youtube.com/watch?v=Llu3WGbJpzc On 13 September 2012 11:25, Ryan Stark efflux...@googlemail.com wrote: Hi. I've not been on my Linux system with Gimp for a bit so Ideally I need to work through exactly how I set that up and how I'm using it. The aconnectgui is how to see and make the connections but in actual fact it's best to do that from command. The connection isn't remembered so rather than set it up via aconnectgui I just run a command every time I start Gimp. As for the colour adjustments. You turn knobs to change colours but you see that colour changing on the colour wheel and can still select there anyway, if you want. It can be used to make small colour changes as you paint or values, opacity, whatever you want. Brush size is an obvious one. You can literally change stuff as you paint a stroke but that can end up a bit glitchy. One problem with Gimp 2.8 is that the top size of the brush is far too big. If you compile from scratch you can change that. This needs to be mentioned in the Gimp developer list. It's also possible to have UI to set that largest size of brush so it's not too big. I've seen the code that needs added to do that. This all needs to be better sorted out to make Gimp more ideal for painting.These are simple changes that need to be in Gimp. Changing it and compiling is too much trouble. All the functions that can be mapped to keyboard can be mapped to MIDI except the MIDI has continuous controller meaning instead of one key command ton say make a brush bigger you have values from 0-127. Obviously this is better. I mentioned that with colour I think you need to set the controller to not go to value 0. I'll have to confirm that but I think value 0 for a colour causes it to turn all colours to 0 or something similar. There is some kind of problem
Re: [Gimp-user] MIDI controllers for controlling brush size and colors [was: Save Export Complaints]
So can you use MIDI in Windows as well? I've never tried that. I'm always assuming Gimp users are Linux but of course that isn't the case. I'm sure I've read there is a problem with it on OSX though. I don't like Gimp OSX. Often there are problems. I stopped using it on OSX. On 13 September 2012 12:07, Ryan Stark efflux...@googlemail.com wrote: You need to set up the Korg using Windows software to get it all exactly as you want. That should work in wine. Gimp will remember all the mappings but the one problem is that Gimp doesn't remember the connection so you have to connect the ALSA output of the MIDI controller to Gimp's input after starting Gimp. This isn't difficult though. It's simply the connection posts number and MIDI channels. One command can do that. That's a bit easier than opening the GUI to be honest. One benefit of using the MIDI controller to adjust colour is that you can create minor adjustments of colour constantly which helps with the fact that Gimp doesn't blend paint on the canvas. To be honest though, Photoshop didn't have that feature for ages and I didn't see it stopping great art in Photoshop. A lot of great Photoshop artists still generally don't use paint blending because they are so used to not having that feature in the past. It's a very over rated feature. It just seems very cool to begin with if you try in it Krita or Mypaint. If you can paint or draw, the lack of that feature is not going to stop you making great paintings. I have been building up a large collection of brushes in Gimp. The default ones were very poor. 2.8 is better but still, I don't think the full power of Gimps brushes is utilised by most people. I find that in Krita and especially Mypaint (although there is a great procedural aspect to the brushes in that app) you can't create as cool brushes as you can in Gimp. Gimp also understands Wacom pens that rotate. Another largely unknown feature (if you have a pen that sends rotate info). Gimp is really a seriously underrated app. Go check out any brilliant art done in Photoshop and Gimp can do all of that easily. On 13 September 2012 11:53, Ryan Stark efflux...@googlemail.com wrote: You can do anything. That's why it's so great. MIDI has continuous controllers and notes. Notes can be mapped as well. Continuous controllers can be set to any value or a button sends that value so say you want a collection of brush sizes, you set a button to send a value anywhere from 0-127 that can be used to set any brush size at the click of a button. On 13 September 2012 11:46, Ryan Stark efflux...@googlemail.com wrote: Yes, you could connect through Jack but Hardware will show up at ALSA so I don't think Jack would actually be a benefit for Gimp use but maybe you'd need this to test with software? ZynaddSubFX can connect via ALSA or Jack (or use Yoshimi) but can you then connect to GIMP somehow maybe via the Jack connection UI where ALSA and Jack MIDI show up? I'll have to leave this for others to test. I'm not on my Linux graphics machine at the moment. I'm on OSX. On 13 September 2012 11:36, Ryan Stark efflux...@googlemail.com wrote: There's a video on youtube of somebody doing it but I don't recommend pushing it this far i.e. changing as you actually make a stroke. That can get a bit glitchy. Also, a keyboard isn't ideal. You want something like that Korg. Before the Korg NanoKontrol, there wasn't anything as ideal but that machine is cheap, small and perfect for the job. http://www.youtube.com/watch?v=Llu3WGbJpzc On 13 September 2012 11:25, Ryan Stark efflux...@googlemail.com wrote: Hi. I've not been on my Linux system with Gimp for a bit so Ideally I need to work through exactly how I set that up and how I'm using it. The aconnectgui is how to see and make the connections but in actual fact it's best to do that from command. The connection isn't remembered so rather than set it up via aconnectgui I just run a command every time I start Gimp. As for the colour adjustments. You turn knobs to change colours but you see that colour changing on the colour wheel and can still select there anyway, if you want. It can be used to make small colour changes as you paint or values, opacity, whatever you want. Brush size is an obvious one. You can literally change stuff as you paint a stroke but that can end up a bit glitchy. One problem with Gimp 2.8 is that the top size of the brush is far too big. If you compile from scratch you can change that. This needs to be mentioned in the Gimp developer list. It's also possible to have UI to set that largest size of brush so it's not too big. I've seen the code that needs added to do that. This all needs to be better sorted out to make Gimp more ideal for painting.These are simple changes that need to be in Gimp. Changing it and compiling is too much trouble. All the functions that can be mapped to keyboard can be mapped to MIDI except the MIDI has
Re: [Gimp-user] MIDI controllers for controlling brush size and colors [was: Save Export Complaints]
I can't even remember the brush size. I'm not looking at Gimp as present, It's just WAY too large in Gimp 2.8. 2.6 was fine. I've not used 2.6 for years so I can't remember everything about it as far as this logarithmic stuff etc is concerned. I'm not even looking at 2.8. I'm on a Mac. Gimp is on my Linux system. I flit from doing music on the Mac then doing graphics on Linux. I had to move off Linux for music unfortunately. It's not advanced enough yet. Next time I work in it for graphics I'll check all of this out. I'll need to compile Gimp to get the brush smaller. We need to collect info about what needs to be done then Gimp needs to be released in some usable state as far as brush sizing. Most users of Gimp are't going to compile and change code and I can't be bothered with that either. At present the situation will make people go to Mypaint or Krita for painting but in my opinion Gimp is still better. Largest brush size needs to be adjustable. As you say, this could be done in preferences. When I looked into how to find the largest brush size in code before compiling, I also noticed that this code had info to add UI to change that but I didn't use that. Now I don't know where I found that code change. It's on the net somewhere but I'll look for it again. On 13 September 2012 12:47, Joao S. O. Bueno gwid...@mpc.com.br wrote: On 13 September 2012 08:26, Ryan Stark efflux...@googlemail.com wrote: Yes, exactly, that is the problem. You can change the default brush largest size before compiling. Presently it's too large and this needs discussed with developers. I found somewhere how to change that code and it's very easy to do. Just find that one value and change it but also some UI that can be added to alter that largest brush size from Gimps UI. My Gimp is currently installed in the standard way. Next time I use it for painting I will compile and I'll document how to do that. At present, I can't even remember how to do that. I'm not even writing this from Linux. Somewhere on my Linux machine is a note on how to do it. This needs changing on Gimp. Whether you are using MIDI or a tablet slider, the largest size of brush is ludicrous. It effects all the brush sizing - stepping it up etc. It's no good. What do you think would be a reasonable largest size multiplier (as opposed to actual brush size)? The current value is 1000.0 - in the previous version it was 10.0.Also, up to GIMP 2.6, feaures that ranged from 0 to 1000.0 (like actual brush radius) would vary in a logarithmic way, meaning that if you started with a value of 5.0, small variations close to that would make changes from 2 - to 20.0 --if you started at 500.00, the same small variations could take you to 150.0 - 1000.0 Maybe, simply having the largest brush size as a value in preferences could make up for all use cases. On 13 September 2012 12:17, Joao S. O. Bueno gwid...@mpc.com.br wrote: On 13 September 2012 07:25, Ryan Stark efflux...@googlemail.com wrote: One problem with Gimp 2.8 is that the top size of the brush is far too big. If you compile from scratch you can change that. This needs to be mentioned in the Gimp developer list. It's also possible to have UI to set that largest size of brush so it's not too big. I've seen the code that needs added to do that. This all needs to be better sorted out to make Gimp more ideal for painting.These are simple changes that need to be in Gimp. Changing it and compiling is too much trouble. Oh well...we used to have logarithmic brush size control. Now, you have a linear space ranging from 0 to 1000.00 - if you have to control the brush size using a 2 cm course MIDI pedal, it simply won' t do -out of the box - But I think it could be controled using the dynamics curves: create a new brush dynamics, map the input control to brush size there, and edit its curve so that the maximum size (right) is at roughly 10% of the graphic height. js -- ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] MIDI controllers for controlling brush size and colors [was: Save Export Complaints]
OK. I'm not looking at Gimp at the moment. I have no source code to compile but before compiling, as far as I can see there is a file called gimppaintoptions.c. In that there are the lines: GIMP_CONFIG_INSTALL_PROP_DOUBLE (object_class, PROP_BRUSH_SIZE brush-size, _(Brush Size), - 1.0, 1000.0, DEFAULT_BRUSH_SIZE, + 1.0, 1.0, DEFAULT_BRUSH_SIZE, GIMP_PARAM_STATIC_STRINGS); I'm not sure if these lines have changes made by me or not. It's just a text file I found on a drive I have. It looks like they don't have changes judging by the values? On 13 September 2012 13:02, Ryan Stark efflux...@googlemail.com wrote: I can't even remember the brush size. I'm not looking at Gimp as present, It's just WAY too large in Gimp 2.8. 2.6 was fine. I've not used 2.6 for years so I can't remember everything about it as far as this logarithmic stuff etc is concerned. I'm not even looking at 2.8. I'm on a Mac. Gimp is on my Linux system. I flit from doing music on the Mac then doing graphics on Linux. I had to move off Linux for music unfortunately. It's not advanced enough yet. Next time I work in it for graphics I'll check all of this out. I'll need to compile Gimp to get the brush smaller. We need to collect info about what needs to be done then Gimp needs to be released in some usable state as far as brush sizing. Most users of Gimp are't going to compile and change code and I can't be bothered with that either. At present the situation will make people go to Mypaint or Krita for painting but in my opinion Gimp is still better. Largest brush size needs to be adjustable. As you say, this could be done in preferences. When I looked into how to find the largest brush size in code before compiling, I also noticed that this code had info to add UI to change that but I didn't use that. Now I don't know where I found that code change. It's on the net somewhere but I'll look for it again. On 13 September 2012 12:47, Joao S. O. Bueno gwid...@mpc.com.br wrote: On 13 September 2012 08:26, Ryan Stark efflux...@googlemail.com wrote: Yes, exactly, that is the problem. You can change the default brush largest size before compiling. Presently it's too large and this needs discussed with developers. I found somewhere how to change that code and it's very easy to do. Just find that one value and change it but also some UI that can be added to alter that largest brush size from Gimps UI. My Gimp is currently installed in the standard way. Next time I use it for painting I will compile and I'll document how to do that. At present, I can't even remember how to do that. I'm not even writing this from Linux. Somewhere on my Linux machine is a note on how to do it. This needs changing on Gimp. Whether you are using MIDI or a tablet slider, the largest size of brush is ludicrous. It effects all the brush sizing - stepping it up etc. It's no good. What do you think would be a reasonable largest size multiplier (as opposed to actual brush size)? The current value is 1000.0 - in the previous version it was 10.0.Also, up to GIMP 2.6, feaures that ranged from 0 to 1000.0 (like actual brush radius) would vary in a logarithmic way, meaning that if you started with a value of 5.0, small variations close to that would make changes from 2 - to 20.0 --if you started at 500.00, the same small variations could take you to 150.0 - 1000.0 Maybe, simply having the largest brush size as a value in preferences could make up for all use cases. On 13 September 2012 12:17, Joao S. O. Bueno gwid...@mpc.com.br wrote: On 13 September 2012 07:25, Ryan Stark efflux...@googlemail.com wrote: One problem with Gimp 2.8 is that the top size of the brush is far too big. If you compile from scratch you can change that. This needs to be mentioned in the Gimp developer list. It's also possible to have UI to set that largest size of brush so it's not too big. I've seen the code that needs added to do that. This all needs to be better sorted out to make Gimp more ideal for painting.These are simple changes that need to be in Gimp. Changing it and compiling is too much trouble. Oh well...we used to have logarithmic brush size control. Now, you have a linear space ranging from 0 to 1000.00 - if you have to control the brush size using a 2 cm course MIDI pedal, it simply won' t do -out of the box - But I think it could be controled using the dynamics curves: create a new brush dynamics, map the input control to brush size there, and edit its curve so that the maximum size (right) is at roughly 10% of the graphic height. js -- ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] Save Export Complaints
I see lots of complaints about the Gimp save and export. I've been using Gimp for ages with this feature. It is entirely logical and I don't understand the complaining. In a DAW (digital audio workstation application) you save the whole project as a session. You export the final file as mixdown in MP3 or whatever other format and you can import audio files into the project. It's similar logic in Gimp and makes total sense. Lots of apps work with this kind of method even when not as crucial as it is with DAW software. ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Save Export Complaints
All DAWs work like this. That's why I used it as an example. DAWs generally work in a non destructive manner and you need to save that info for later editing. Not destructively export it without saving the whole project. 2D image editing has many non destructive aspects. DAWs have lots of tracks which can be equated to Gimp's layers. Some image editing apps are totally non destructive. Sure, there are many apps that do not work with save and export being different dialogs this but that doesn't make them right. If you open say a .png or whatever format in Gimp, work on it then save as in the old 2.6 method to .png you are not really saving all that exists in the Gimp project, you are exporting the file back to .png. Hence it is completely logical to have this separate. In the new system it's harder to accidentally export when really you wanted to save the Gimp project. On 12 September 2012 13:54, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Wed, Sep 12, 2012 at 4:43 PM, maderios wrote: People will leave the world of free software to turn to proprietary. Isn't it where four riders of the Apocalypse emerge? Oh, and Ronnie :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Save Export Complaints
I see all this critique as completely ridiculous. That's why I posted about it. Gimp is a professional level app and it's free. What more do people want? I use Gimp for painting purposes so I end up with complex Gimp projects with many layers etc so the new save or export makes total sense. I can't accidentally lose my work. Also, Gimp gets lots of critique from people doing digital painting. Also ridiculous. Sure, it lacks some features for this like brushes that mix on the canvas or easy rotating of canvas but in actuality the rest of Gimp's very powerful features still makes it the best painting app. Gimp also has one completely unique and brilliant feature for use with painting. Most graphic tablets and cintiqs have poor sliders for operating various functions such as brush size or whatever. Since I do music I understand MIDI. Gimp can be hooked up to a MIDI controller for controlling brush sizes or anything else. This is a superb feature. You can buy a little MIDI controller with lots of knobs and sliders. VASTLY superior to sliders on graphics tablets. On 12 September 2012 14:04, Øyvind Kolås pip...@gimp.org wrote: On Wed, Sep 12, 2012 at 2:43 PM, maderios mader...@gmail.com wrote: I use .xcf files but my friends, my family members and most people, I think, don't use .xcf. They need an image editor, not an xcf editor. People will leave the world of free software to turn to proprietary. Gimp is no longer the universal Swiss army knife of image editing, it's a fact. GIMP has not lost any capability, all it has done is re-arrange some capabilities for greater consistency - as well as opening up for extending the capabilities of XCF - like storing undo history and more thing that make less sense for the external formats. For GIMP it is a good thing that people take changes personally - it means they care deeply about GIMP and how they use it, make it seem unlikely that they switch no matter how much venom they directed at the volunteers that spend their time actually making it happen. :) /Ø ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Save Export Complaints
The basic problem appears to be that casual users of Gimp who just want to open an image, edit then save it back to the original format don't really seem to understand the .xfc format and what that does. If they spent a few minutes investigating that they would understand the change instead of immediately complaining. If this was some kind of show stopper change then I'd see the point of the complaining. On 12 September 2012 14:50, jfrazie...@nc.rr.com wrote: I use .xcf files but my friends, my family members and most people, I think, don't use .xcf. Yes, I think you have just about FINALLY hit the point. I am NOT a developer for GIMP, but I am enthusiastically in support of this new change so that I CANNOT loose my multi-layer composition without explicit consent as could (and did a few times) in previous versions of GIMP.I am speaking for myself here, but I would say GIMP wants people to use GIMP's native file format. There are a large number of reasons for this, but saving multi-layer compositions is a key one. I suspect another reason is to attempt to force recognition by print shops. Ask how many print shops support psd files but not xcf? I would bet that number would be 20:1 and one way to change that would be to try to push the xcf usage among professional artists who use such print shops far more than the average joe blow on the street. They need an image editor, not an xcf editor. And these same joe blow users are NOT the intended audience of GIMP as has been stated likeoh... 500 times or so... People will leave the world of free software to turn to proprietary. Yep, and that's their right... why are you pushing so hard to keep them with a software that is not targeting them as it's core demographic? Especially when it's not a commercial project where anyone makes money from? Gimp is no longer the universal Swiss army knife of image editing, it's a fact. Umm... what are you smoking? The change in question did not REMOVE any functionality for editing images. It did not REMOVE any functionality as to what format files could be saved/exported to. It only moved functionality to create a CLEAR distinction between Saving to it's native format, and Exporting to every other format. More importantly as mentioned several hundred times, it reduced the code complexity AND(as much as possible barring power loss or computer crashes) now prevents one from accidentally loosing a multi-layer composition(which is the most important feature) ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Save Export Complaints
Do you really use it ? Ergonomically speaking, Gimp is now an xcf editor. Gimp is an image editor that can import or export whatever you want but has it's own savable format for all the layers and other data to store for later editing. Hence the differentiation of saving and exporting. Print shops ask for png, jpeg or tiff, not psd So Gimp is no problem here then. On 12 September 2012 15:35, maderios mader...@gmail.com wrote: On 09/12/2012 03:50 PM, jfrazie...@nc.rr.com wrote: I use .xcf files but my friends, my family members and most people, I think, don't use .xcf. Yes, I think you have just about FINALLY hit the point. I am NOT a developer for GIMP, but I am enthusiastically in support of this new change so that I CANNOT loose my multi-layer composition without explicit consent as could (and did a few times) in previous versions of GIMP.I am speaking for myself here, but I would say GIMP wants people to use GIMP's native file format. There are a large number of reasons for this, but saving multi-layer compositions is a key one. I suspect another reason is to attempt to force recognition by print shops. Ask how many print shops support psd files but not xcf? I would bet that number would be 20:1 and one way to change that would be to try to push the xcf usage among professional artists who use such print shops far more than the average joe blow on the street. Print shops ask for png, jpeg or tiff, not psd They need an image editor, not an xcf editor. And these same joe blow users are NOT the intended audience of GIMP as has been stated likeoh... 500 times or so... People will leave the world of free software to turn to proprietary. Yep, and that's their right... why are you pushing so hard to keep them with a software that is not targeting them as it's core demographic? Especially when it's not a commercial project where anyone makes money from? Strange and interesting point of view... Your message to these people is go out. Welcome in the Happy World of Free Software... Happily, you're not representative. Free Software philosophy is opening, not closing. About GNU/Linux philosophy https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar I hope that gimp does not become a cathedral Gimp is no longer the universal Swiss army knife of image editing, it's a fact. Umm... what are you smoking? The change in question did not REMOVE any functionality for editing images. It did not REMOVE any functionality as to what format files could be saved/exported to. It only moved functionality to create a CLEAR distinction between Saving to it's native format, and Exporting to every other format. More importantly as mentioned several hundred times, it reduced the code complexity AND(as much as possible barring power loss or computer crashes) now prevents one from accidentally loosing a multi-layer composition(which is the most important feature) Do you really use it ? Ergonomically speaking, Gimp is now an xcf editor. Greetings -- Maderios ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Save Export Complaints
It's not logical to save a whole session if all one does is touch up a jpeg file. No, so then the logical thing is to export. Why is this such a problem? Export is separated from save dialog to make it difficult to accidentally lose you data. If you accidentally save to xcf rather than export then no problem. If you do the opposite then it's possible disaster. There have been a few occasions in the earlier Gimp where I've exported when I should have saved. Not even a total accident in some cases. I just though the editing was done whereas the new way tends to remind me to keep the xcf. For very casual users, this may not be understood but the new way of doing it is more friendly to people who understand it. It's not difficult to deal with. Should Gimp be dumbed right down to cater for people who don't understand things or should Gimp do things the right way? Sometimes free software developers can make bad choices, that's true, but sometimes (as in this case) they don't pander to what many users want, instead they make the right change for the better and I believe that most Gimp users will in fact realize that this simple change is better. On 12 September 2012 16:37, Ken Warner kwarner...@verizon.net wrote: It's not logical to save a whole session if all one does is touch up a jpeg file. On the other hand, for people who do complicated image building over many sessions, it makes sense to save a project and in that case it would be logical to have an option that allows gimp to open the previous project on restart. That would prevent work loss. On 9/12/2012 3:30 AM, Ryan Stark wrote: I see lots of complaints about the Gimp save and export. I've been using Gimp for ages with this feature. It is entirely logical and I don't understand the complaining. In a DAW (digital audio workstation application) you save the whole project as a session. You export the final file as mixdown in MP3 or whatever other format and you can import audio files into the project. It's similar logic in Gimp and makes total sense. Lots of apps work with this kind of method even when not as crucial as it is with DAW software. ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Save Export Complaints
Now that's a really neat idea. What (affordable) MIDI controller do you like? I use a Korg NanoKontrol. The one here with the sliders and knobs: http://www.korg.co.uk/products/software_controllers/nano2/sc_nano2.php I'm not sure how much it is but it's cheap compared to what there used to be. It's very small and portable so ideal for Gimp. It communicates with alsa (via USB). You have a small GUI app called aconnectgui where you can see the Korg output and Gimp input. You just connect them up. I actually do it from command but that's because I couldn't find aconnectgui in the Arch repo. Here's some info from the Ubuntu site: https://apps.ubuntu.com/cat/applications/precise/aconnectgui/ One problem is that you need the Korg editor (Windows or OSX) to change MIDI functions on the NanoKontrol. That should work via wine but I didn't try that. The reason you have to change some things is that by default some of the switches are momentary or maybe that wasn't the problem. I can't remember exactly but I had to edit a few things. I'm not on Linux at the moment to look at it exactly but you'll find MIDI under Input controllers in Gimp. You have a vast choice of Gimp parameters and you set them by choosing the one you want then moving the appropriate knob on the controller to set it to the parameter. There is stacks you can do. I like to set it to change colours i.e. one knob will increase red etc. Selecting colours, values etc in the colour wheel suddenly starts to become obsolete. Actually, thinking about that particular function, I think that was why I had to edit the Korg via its OSX(or Windows) editor. I think you need that particular value to not go to zero value. Probably I should document all this somewhere properly. The huge advantage over a graphics tablet slider is that MIDI has continuous controllers. This means you move the knobs and sliders up and down to exact values. You are not sending a keyboard command. It's really quite ingenious whoever thought of adding that to Gimp and I bet hardly anyone uses it. On 12 September 2012 17:02, Ryan Stark efflux...@googlemail.com wrote: It's not logical to save a whole session if all one does is touch up a jpeg file. No, so then the logical thing is to export. Why is this such a problem? Export is separated from save dialog to make it difficult to accidentally lose you data. If you accidentally save to xcf rather than export then no problem. If you do the opposite then it's possible disaster. There have been a few occasions in the earlier Gimp where I've exported when I should have saved. Not even a total accident in some cases. I just though the editing was done whereas the new way tends to remind me to keep the xcf. For very casual users, this may not be understood but the new way of doing it is more friendly to people who understand it. It's not difficult to deal with. Should Gimp be dumbed right down to cater for people who don't understand things or should Gimp do things the right way? Sometimes free software developers can make bad choices, that's true, but sometimes (as in this case) they don't pander to what many users want, instead they make the right change for the better and I believe that most Gimp users will in fact realize that this simple change is better. On 12 September 2012 16:37, Ken Warner kwarner...@verizon.net wrote: It's not logical to save a whole session if all one does is touch up a jpeg file. On the other hand, for people who do complicated image building over many sessions, it makes sense to save a project and in that case it would be logical to have an option that allows gimp to open the previous project on restart. That would prevent work loss. On 9/12/2012 3:30 AM, Ryan Stark wrote: I see lots of complaints about the Gimp save and export. I've been using Gimp for ages with this feature. It is entirely logical and I don't understand the complaining. In a DAW (digital audio workstation application) you save the whole project as a session. You export the final file as mixdown in MP3 or whatever other format and you can import audio files into the project. It's similar logic in Gimp and makes total sense. Lots of apps work with this kind of method even when not as crucial as it is with DAW software. ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
