Requests/Wishlist

[A_SN]

Oh, I did not even think about importing additional sounds until now... hm, breaking the lossless mode is not fine, of course (well I don't understand why adding silence to a layer should break the lossless mode, but you will, probably. ). Maybe you could just let the user decide: Insert a message offering to crop the audio to import, resize it without the lossless mode on that layer or just cancel the import.

I'm actually wondering how PS works internally using the layers - at the moment they are just visual, aren't they? If you offer to import sounds, you'll necessarily have to implement some kind of track management, e.g. lossless-mode on/off for each layer separately, sound and picture based layers, won't you? My idea for the moment was just to add an import/export feature for visual layers - probably this is much less work for you but will already offer many creative possibilities by bringing the possibilities of external image editing to mulitlayer-projects. And if someone wants to import another sound file, he might even workaround it by opening the file to import all alone at first, exporting it as .bmp and then importing it into his main project...

Well the lossless mode works in the following way: when you open a sound it saves the original sound and its image as it was originally analysed, and keeps that pair around until another sound is opened. If it's another image those are still around in case that image can be used for lossless mode by comparing the original image to the new image to modify (filter) the original sound.

If the new image is different in size it just assumes that image does not match the original image-sound pair, and it wouldn't know what to do with it anyway, if it's shorter then how can we assumed it's cropped, and if it's longer do we pad it with silence? (it's kind of pointless).

For importing I think it's a good idea to let the user choose between either a fitted import or a cropped import, maybe even an expanding import for adding longer images/sounds (if you don't care about lossless). In the eventual rewrite I want to have a more DAW-like approach, basically make it a DAW except it would be mostly based on graphical data and processing instead of pure audio, so yeah I'd like to have separate synthesis modes for each layer/groups of layers/track which would be lossless mode, noise synthesis (Photosounder's current default), additive FM synthesis for vector layers and possibly a simple audio mode where you could just add sounds (let's say you want to overlay a drum loop without processing it, but still want to see it visually and like adjust its volume) without the CPU and memory expense of (live!) lossless processing. And the way I see it this way you wouldn't have a fixed document size, it would be more like a multitrack editor where how you position each track determines the length of it, so each "track" could exist more independently from the rest, mostly for lossless.

Normally I'm not interested in the sound produced from the whole image. Just part of it.

So: would it be possible to add loop start/end markers, like sample players normally have? These would control which part of the image is used to create sound and it would be used also when saving the image.

This way I wouldn't need to load the output wav file to a sample editor and crop the sound. And since the sound changes depending on the image, it's much easier to find the correct loop start/end based on the source image - since the waveform usually looks like monotonous noise in a sample editor.

IMO this feature would be super useful.

Well let's say you want to crop between 50 seconds and 72 seconds, you can already crop using a two-line script containing the following commands:

Code: Select all

Move layer -50 sec x +0 st
Crop 22 sec x 100 %

(or you can do the Move part yourself using the move tool in Photosounder by moving your image to the left until where you want it to start is at 0 seconds and then do the cropping using a script)

I know it would be better if there was a built-in tool for that as you described it but I can't really make dialogs or text input or new types of controls because I'm using a framework (SDL) which is better suited for 2D game development, which is a big roadblock, hence the Qt rewrite. Also it breaks the lossless mode for reasons outlined above, I know I'll make something more suitable in the rewrite but in the meantime it would be hard to really change that.

Wait I just had an idea, I could make a dumb simple Crop tool which would consist it in making the click of the mouse on the image crop everything right of it. That could do the trick. I could do one that does the same for cutting off the left side although I have mixed feelings about how it might affect some convolution modes if you crop a multi-layer document, but I guess I could do that too.

[Waldbaer]

Thank you for your detailed answer. I probably understood it not that deeply, but it seems to me that the problem of the lossless mode is, that the comparison itself simply does not know what to do if one of the images that are compared does not have a corresponding pixel. As a more or less layman, I'd suppose that you could add a kind of function that will check for differences in size before the actual comparison process and then the comparison can react correctly (if an image does not have the corresponding pixel(s) - just ignore it and use the other ones exclusively). Well, probably it's kinda ridiculous if you really need me to explain how to program your application...

Anyways, your far-future plan to expand and completely rewrite it sounds great, but also very complicated and will probably take a long time - I hope you'll get this done; maybe the current MU Promo gave you some of the needed budget.

The cropping-mini-tool sounds also useful. And in the rewritten version, you can add a real cycling-GUI including part-bouncing (like e.g. in Logic).

By the way, I think its generally a little difficult to keep track of the resolution of the image the program is working with. As far as I got it (please correct if I'm wrong):
- the image size is not changed any further as soon as the image is created (new) or opened
- the width of a new image depends on the current width of the window
- the height of a new image is always 9.5 octaves (like from 27.5-20k Hz) * bands_per_octave in config.txt, no matter what size of window or min/max frequency settings
This leads me especially to the following question: Why is the size in height always constant and the width depends on something funny as the current window size? That means for me: always start your project using a window as big as possible; if you need a higher horizontal resolution, buy a bigger monitor; somehow silly, I think. Maybe you could just add two arrow buttons on the right side of the seconds-scale to crop or extend the image (click=1px, hold=repeat, hold longer=repeat faster or bigger steps; maybe always show the current size during the process)? That would also be a more versatile alternative to your cropping tool, too and still needs no text input.
For the height (=frequency) it would have more sense in my eyes, if also the resolution (=bands per octave) remains constant, not the size (=complete pixel count - independent from the min/max frequency). If I think about it longer, this might be problematic as soon as you really work using photos; I'm mostly working completely from scratch until now. Maybe you could add a selection near the min/max knobs to select either to "keep picture resolution" or "keep pixel/octave"
E.g. for external editing it might be useful to know the current resolution - in the standard 5px=1semitone - maybe you could add a place where this is shown, too, so it's not necessary to think about the mathematics behind it all the time - what was it? log(Max/min)/log(2)=current bands per octave, took me about 30 seconds because I just used it, the first one took longer - I think you'll get my point.

[Waldbaer]

double post

[sl1914]

Well let's say you want to crop between 50 seconds and 72 seconds, you can already crop using a two-line script containing the following commands:

Code: Select all

Move layer -50 sec x +0 st
Crop 22 sec x 100 %

(or you can do the Move part yourself using the move tool in Photosounder by moving your image to the left until where you want it to start is at 0 seconds and then do the cropping using a script)

I know it would be better if there was a built-in tool for that as you described it but I can't really make dialogs or text input or new types of controls because I'm using a framework (SDL) which is better suited for 2D game development, which is a big roadblock, hence the Qt rewrite. Also it breaks the lossless mode for reasons outlined above, I know I'll make something more suitable in the rewrite but in the meantime it would be hard to really change that.

Wait I just had an idea, I could make a dumb simple Crop tool which would consist it in making the click of the mouse on the image crop everything right of it. That could do the trick. I could do one that does the same for cutting off the left side although I have mixed feelings about how it might affect some convolution modes if you crop a multi-layer document, but I guess I could do that too.

Thanks for the reply. Now I know there is *a* way to do it already. I just feel that having loop start/end markers would be the best solution for the user, since one could HEAR the result before doing actual crop. First you put markers somewhere and listen to the looped play. If the area is not right, keep moving markers until it sounds right and THEN crop.
If the UI part is a problem, wouldn't it be possible to show small loop markers (like rectangles really) between the file name and colored waveform?

[A_SN]

And in the rewritten version, you can add a real cycling-GUI including part-bouncing (like e.g. in Logic).

What is that? I'm not familiar with Logic.

Why is the size in height always constant and the width depends on something funny as the current window size?

Well ideally I would have had a dialog for that, but there's the problem of not being able to make any dialogs... so I just chose the current on-screen size. But once again this is something that can be remedied through scripting, a Crop command will do the trick (as always with those you can choose to set it in whichever unit you want, be it percents (of the current size, useful for doubling a size for instance), seconds or pixels).

E.g. for external editing it might be useful to know the current resolution - in the standard 5px=1semitone - maybe you could add a place where this is shown, too, so it's not necessary to think about the mathematics behind it all the time - what was it? log(Max/min)/log(2)=current bands per octave, took me about 30 seconds because I just used it, the first one took longer - I think you'll get my point.

Well you know how many pixels there are in an octave (60) so you either didn't change that setting or you did and you know what it is!

Thanks for the reply. Now I know there is *a* way to do it already. I just feel that having loop start/end markers would be the best solution for the user, since one could HEAR the result before doing actual crop. First you put markers somewhere and listen to the looped play. If the area is not right, keep moving markers until it sounds right and THEN crop.
If the UI part is a problem, wouldn't it be possible to show small loop markers (like rectangles really) between the file name and colored waveform?

Hmmm possibly, I'd have to look into that.

[Waldbaer]

And in the rewritten version, you can add a real cycling-GUI including part-bouncing (like e.g. in Logic).

What is that? I'm not familiar with Logic.

Nothing special, it's just a Bar above the part of the timeline where you can set the cursor position. In this bar, you can define the position and length of the cycle via click&drag and with a button, you can activate and deactivate it. Here's a screenshot how it looks like (when it's activated, otherwise the green bar would be grey):

...

E.g. for external editing it might be useful to know the current resolution - in the standard 5px=1semitone - maybe you could add a place where this is shown, too, so it's not necessary to think about the mathematics behind it all the time - what was it? log(Max/min)/log(2)=current bands per octave, took me about 30 seconds because I just used it, the first one took longer - I think you'll get my point.

Well you know how many pixels there are in an octave (60) so you either didn't change that setting or you did and you know what it is!

The problem occurs if you change the values of min/max frequency while working, because the image size stays the same as in the beginning. Of course I may calculate it, but it gets a little complicated as soon as you don't have complete octaves (even that might be a little challenge to find out for some guys). Well, I CAN figure out what to type into my calculator, it's just not very comfortable and maybe some other users don't figure it out. That's why I suggest to add a little monitor for this. But of course these are only suggestions, you don't have to necessarily implement that.

But I definitely should take a deeper look into the scripting... thanks for encouraging!
PS: I think the calculation in the post above was even wrong, it should be this way, I think:
current bands per octave = resolution of the image / (log(Max/min)/log(2))
...took me some more minutes this time.

[sl1914]

Thanks for the reply. Now I know there is *a* way to do it already. I just feel that having loop start/end markers would be the best solution for the user, since one could HEAR the result before doing actual crop. First you put markers somewhere and listen to the looped play. If the area is not right, keep moving markers until it sounds right and THEN crop.
If the UI part is a problem, wouldn't it be possible to show small loop markers (like rectangles really) between the file name and colored waveform?

Hmmm possibly, I'd have to look into that.

I hope this will be possible.

[Soman]

How about full screen mode for Spiral? Or at least a resizable Interface...

[XComposer]

I'm going to use Photosounder a lot in these days and I confirm that the possibility to open a second sound or a second image in a new layer would be very welcome and would make the program much more powerful; something like a command "open as new layer" (there is a similar command in GIMP). I hope that this will be possible in the future.

[A_SN]

I'm going to use Photosounder a lot in these days and I confirm that the possibility to open a second sound or a second image in a new layer would be very welcome and would make the program much more powerful; something like a command "open as new layer" (there is a similar command in GIMP). I hope that this will be possible in the future.

Yeah, it will be in Photosounder 2.0 of course. One of the most sorely missed features in the current Photosounder as far as I'm concerned.

[lnikj]

Wow. This is a pretty spectacular necrothread reanimation !

It is great to hear that this is still in development. Any detail on forthcoming features or even a forecast on a possible release date?

[A_SN]

Wow. This is a pretty spectacular necrothread reanimation !

It is great to hear that this is still in development. Any detail on forthcoming features or even a forecast on a possible release date?

I have no idea about a release date, right now I'm working on the basics of the interface, so it's still pretty early.

My initial plan is to have all the features the current thing has (it's a full rewrite), but already with some significant differences:

-it will be more stereo, first off it will look like Spiral's colour scheme for visualisation, and it will probably have options to make imported pictures be stereo depending on the colours
-it will feature things like spline curves (like in SplineEQ) to control a lot of things
-the volume won't be autonormalised anymore, it will depend on the brightness of the image, which itself won't be autonormalised either
-the synthesis will be live (probably in lossless mode too)
-in Photosounder 1.x the synthesis would adapt to the resolution of the image, which made opening large images very slow and impractical. Now it will be the opposite, the synthesis parameters (like, how many bands we get) will be set independently of the material used
-you'll be able to put many different kinds of files (importing) together so that it can be flexible
-I might use a different sound analysis technique, but that's not done yet so I don't even know if my idea will work well enough
-the emphasis will be put on the interface, on having a really good system that I can expand easily and that will provide everything needed, because that's where Photosounder 1.x sinned the most.

However I must warn that I'll go for an unusual approach, I'm doing a zoomable interface. I've already got that working (zoom with the mouse scroll, and in zoom mode the mouse cursor stays in the center of the screen, it's everything else that moves, so you can pan around wildly in a continuous and natural way. It's really good for drawing/editing things since you're never blocked by the limits of the window or screen) and I quite like it, but it's rather unusual. My current idea is that the screen will be split in two areas, one for the whole image thing and another one for everything else. Both areas will be zoomable independently, which for the image editing/visualising area probably make immediate sense but less so for the other one. So that other area would have lots of small labeled rectangular areas, all laid out in one view in a sensible manner, and basically when you'd zoom in on them it would reveal sorts of dialog boxes, except they'd all be already open and not floating in the middle of the screen, but rather they'd all have their specific place. So you could go around from a "dialog" area to another, doing changes, and at the same time seeing their effect on the image side of the screen. You could also zoom in on a simple button and as you'd zoom until the little button takes up most of the screen you'd have additional small controls appearing inside it allowing you to do things related to that button, like for instance assigning a keyboard shortcut to activate that button from the keyboard. I would also like to put lots of little squares that would look like [?] and when you'd zoom in on them you'd get a text, for instance a detailed explanation of what a parameter or feature does. So instead of having to refer to a manual for everything you'd have an explanation for anything right where you need it, which is in the same place as the feature you're wondering about.

Maybe later I can do a little GIF to show you guys how it would be like. So far I haven't done anything like an image editor but I've done some sort of typeface visualiser, the interface elements are still crude (I just started on working on buttons) but the whole zooming approach is quite polished already.

[lnikj]

Thanks for your full and detailed reply.

I have no idea about a release date, right now I'm working on the basics of the interface, so it's still pretty early.

My initial plan is to have all the features the current thing has (it's a full rewrite), but already with some significant differences:

-it will be more stereo, first off it will look like Spiral's colour scheme for visualisation, and it will probably have options to make imported pictures be stereo depending on the colours

For the old metasynthers it would be great if you followed the red-green 'paradigm' here ?

-it will feature things like spline curves (like in SplineEQ) to control a lot of things

Your curves are so easy to manipulate so that would be good

-the volume won't be autonormalised anymore, it will depend on the brightness of the image, which itself won't be autonormalised either
-the synthesis will be live (probably in lossless mode too)

Any more info on the type of synthesis?

-in Photosounder 1.x the synthesis would adapt to the resolution of the image, which made opening large images very slow and impractical. Now it will be the opposite, the synthesis parameters (like, how many bands we get) will be set independently of the material used

not that I have a D810 but this sounds a better approach

-you'll be able to put many different kinds of files (importing) together so that it can be flexible

mixing audio and images?

-I might use a different sound analysis technique, but that's not done yet so I don't even know if my idea will work well enough
-the emphasis will be put on the interface, on having a really good system that I can expand easily and that will provide everything needed, because that's where Photosounder 1.x sinned the most.

However I must warn that I'll go for an unusual approach, I'm doing a zoomable interface. I've already got that working (zoom with the mouse scroll, and in zoom mode the mouse cursor stays in the center of the screen, it's everything else that moves, so you can pan around wildly in a continuous and natural way. It's really good for drawing/editing things since you're never blocked by the limits of the window or screen) and I quite like it, but it's rather unusual. My current idea is that the screen will be split in two areas, one for the whole image thing and another one for everything else. Both areas will be zoomable independently, which for the image editing/visualising area probably make immediate sense but less so for the other one. So that other area would have lots of small labeled rectangular areas, all laid out in one view in a sensible manner, and basically when you'd zoom in on them it would reveal sorts of dialog boxes, except they'd all be already open and not floating in the middle of the screen, but rather they'd all have their specific place. So you could go around from a "dialog" area to another, doing changes, and at the same time seeing their effect on the image side of the screen. You could also zoom in on a simple button and as you'd zoom until the little button takes up most of the screen you'd have additional small controls appearing inside it allowing you to do things related to that button, like for instance assigning a keyboard shortcut to activate that button from the keyboard. I would also like to put lots of little squares that would look like [?] and when you'd zoom in on them you'd get a text, for instance a detailed explanation of what a parameter or feature does. So instead of having to refer to a manual for everything you'd have an explanation for anything right where you need it, which is in the same place as the feature you're wondering about.

anything zoomable with my crappy eyesight sounds good ...

Maybe later I can do a little GIF to show you guys how it would be like. So far I haven't done anything like an image editor but I've done some sort of typeface visualiser, the interface elements are still crude (I just started on working on buttons) but the whole zooming approach is quite polished already.

... the GIF would be great so I can better envisage it.

It all sounds great and I'd be very happy to alpha test it

[A_SN]

For the old metasynthers it would be great if you followed the red-green 'paradigm' here ?

For importing pictures it could be an option (I'll try to keep it flexible), for visualization definitely no. The reason for that is that green is perceptually several times brighter than red, so that gives you a bias towards whatever green represents. I'll stick to Spiral's pan colouring, I think it's pretty great.

Any more info on the type of synthesis?

Same as before, except all live. Later I might add FM synthesis using thin vector lines.

mixing audio and images?

Yes. Lots of people like to turn images into sound, but actually a more interesting thing is to modulate a sound with an image (like vocoding), it can make more interesting sounds and you might still be able to recognise the picture.

anything zoomable with my crappy eyesight sounds good ...

Yes that's an interesting aspect about it, because you can zoom on anything you want it makes a same interface work fine on really tiny screens or without putting on your glasses.

Okay here's a GIF. For the first few seconds I'm using the normal mouse cursor (which is invisible in the capture, oops!) which works pretty normally, then I just use the zooming mode that allows you to move around without limits.


The interface is very very crude, and I don't even like how buttons look, but that gives you an idea of the basic principle.

[lnikj]

For importing pictures it could be an option (I'll try to keep it flexible), for visualization definitely no. The reason for that is that green is perceptually several times brighter than red, so that gives you a bias towards whatever green represents. I'll stick to Spiral's pan colouring, I think it's pretty great.

Ok, got you, I think. Because of the 2 Gs for every R and B in most sensors?

Yes. Lots of people like to turn images into sound, but actually a more interesting thing is to modulate a sound with an image (like vocoding), it can make more interesting sounds and you might still be able to recognise the picture.

I am fascinated. When I occasionally try to make music rather than just experimenting with stuff, I generally try to express the Atlantic storms and deserted melancholy of the coast where I live in winter, which I also photograph extensively. I am always looking to bring these things closer so I am, as I said, fascinated by what you are suggesting, though I don't really understand it?

Okay here's a GIF. For the first few seconds I'm using the normal mouse cursor (which is invisible in the capture, oops!) which works pretty normally, then I just use the zooming mode that allows you to move around without limits.

The interface is very very crude, and I don't even like how buttons look, but that gives you an idea of the basic principle.

Wow

Gimme.