Hello Cal! I'm "quite" sure he meant in general just editing, manipulate as in change. I suppose I'm as interested as Massy in such an editor. Console apps preferred. :-) Warmly yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Saturday 16 April 2011 10.57.46 Julien Claassen wrote: I'm currently writing a small collections of command line applications (thanks goes to rosea.grammostola for making me doing it) named AutoSFZ where the main app generates SFZ files from samples found in a folder structure. This is because I need to make Natural Drum Kit and a few other samples ready for the CVS version of Linuxsampler. What should I think about when doing this with blind people in mind? Is it enough when the application just do the job when receiving command line parameters in order to do the job? Will for example a status message that prints out "Processing sample 16253 of 23957 samples..." to the same line during the processing make trouble for you? Will an ordinary man page and program usage info with the parameter --help work or is it better with HTML documentation or clean text? What is best in your and S. Massy's world and what is "good enoght"? Jostein

Hi, I don't have much to add to what Julien said. See comments below. On Sat, Apr 16, 2011 at 01:27:49PM +0200, Julien Claassen wrote: Yes indeed! :) In general, the simpler (as per unix pholosophy) a programme is, the more accessible it is at the same time. If it's scriptable and/or accessible over a network connection, it's probably accessible to to blind people as well. Which is in fact true even for sighted people, if you have more than, say 50 samples. Something like: "Processed X samples in T seconds, with W warnings and E errors" ...would be great. Or better yet, a --log option which would generate full reports might be useful, especially if processing a large library. Yes, I think a lot of people out there need to create SFZ files out of their sample libraries. Cheers, S.M. --

On Sat, Apr 16, 2011 at 10:57:46AM +0200, Julien Claassen wrote: Right. As in manipulate parameters. I just thought, since it's fairly straightforward mark-up, someone might have done it, at least in part. These are really great synths, but, if one can't use the GUI, one is restricted to using existing patches and/or editing them by hand, which is feasible, but not exactly straightforward. I guess it has to go on my "if I ever have the time" list. :) Cheers, S.M. --

On Mon, Apr 18, 2011 at 01:23:01AM +1000, cal wrote: Yes indeed! In fact, it would be a far better alternative than simply editing the patch, as one could then presumably hear the results in real-time and experiment more easily. The only other thing that would be needed then, would be the ability to ask yoshimi to save the current patch to file. Cheers, S.M. --

On 18/04/11 02:32, Julien Claassen wrote: Shall do. For now it's on the "of interest" list, not quite the "to do" list. There's been pressure on for midi learn in yoshimi, and this case is probably the first sound reason I've heard for making almost any of the synth controls mappable to midi controllers. Given the number of parameters involved, the potential complexity of tying all that together in a sane, functional fashion does look frightening though. We'll see. cheers, Cal

Julien Claassen wrote: "That's what I really love about open source development. You stand a chance." - Not really true, at least, not as a sweeping general statement about open vs closed source, it depends on the developer, in this case you are fortunate that the developer will listen to and consider requests for features, but sometimes this is true of closed projects too (I'm always happy to listen to feature requests, bug reports etc etc, there are just other reasons why its not possible to open source my code). Equally, you may find an open source project driven by developers who simply don't want to consider feature requests if they don't fit with their own priorities of what is needed - its obviously true that open source allows you to add those features yourself if you have the skills, but I would expect the vast majority of open source *users* don't have the skills (or time) required to pick up a project and just start coding effective solutions to all the features they require.

On Mon, Apr 18, 2011 at 8:55 AM, Julien Claassen <julien(a)c-lab.de> wrote: to a niche than being about commercial vs FOSS. --Steve

Hello Massy! Ramblngs they might be, but they are certainly interesting. It's nice to hear about comparisons from blind people, who actually tried without prejudging and what you find about such things. Warmly yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Getting pretty OT here, but here we go anyway. On Mon, Apr 18, 2011 at 08:12:27PM +0100, Folderol wrote: Well, I think our lot is no different from the lot faced by any minority: in a world where virtually everybody sees and where sight ranks before any other senses in terms of social interaction, how can people, or even society, be expected to have a passing thought for that 0.x% of the population that can't? That's why you'll see Julien and I, and no doubt others, tapping people on the shoulder once in a while and saying, "This application you just released sounds wonderfully useful, only, I can't use it." No obligation attaches, and I for one don't take offence if people don't act on it, but if we didn't do that, then we'd soon be relegated to the world of tape and analogue mixers (nothing wrong with them, btw) while progress marches on. Same goes for all matters of accessibility. [...] > I would be very pleased to see command-line controls extended for yoshimi. I've > no idea how much extra work that would make for Cal - it's not as if he was > sitting around twiddling his thumbs :) > Actually, I commented somewhere (can't remember where now) that this would also > make automation easier. What you can type into the keyboard, can also be fed in > from a script. Philosophy put aside, I believe that is also why Linux is a better platform for blind people, because, no matter how many sleek new applications are designed and how much 3D they add to compiz, there is still a fairly solid core of people who need and use the command-line on a regular basis, even if it's for batch processing or other basic tasks, this keeps the door open for us. Cheers, S.M. > -- > Will J Godfrey > http://www.musically.me.uk > Say you have a poem and I have a tune. > Exchange them and we can both have a poem, a tune, and a song. > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-user --

Julien Claassen wrote: I'd say a little more. And many of the blind in music are highly successful, so you'd think there'd be more interest in the world of music-making software being accessible to the blind. Of course, someone like Stevie Wonder can afford to pay a lot more for such accessibility than others ... -- David gnome(a)hawaii.rr.com authenticity, honesty, community

S. Massy wrote: Actually, I'd think that if you have your DAW set up so you're interacting with it solely through hardware controls, you'd have the best accessibility: you listen to the sound, modify and control it via the hardware. I just think there's no need whatever for a musician to require anything visual in order to make sound. I've seen too many blind musicians who are amazingly gifted partly because their brains have shifted visual-processing neurons to audio-processing. -- David gnome(a)hawaii.rr.com authenticity, honesty, community

Hello1 Well there are a few reasons - nowadays -, why you would need visual feedbacks. I'm thinking of alligning audio to other audio and a metronome/clicktrack. If you need that in "perfect" sync and have acoustic instruments - i.e. nothing, that you can sequence -, then a visual feedback is the way to go. Another one of course is things like graphic multiband EQ, where you are looking for fine peaks at exact frequencies - well as fine as the output can be. Still, I can handle a four band EQ and possibly a ten band EQ, but beyond that... I suppose it's possible, but seeing the things people have in mind for these, visual or other analytic feedback is very helpful. I thought about such things quite a bit. But all the good solutions I came up with are very case specific or just not realtime at all, which makes it very useable, but a pain in the ass for all the people, that can have it otherwise. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Massy! Hm, maybe you're right and taking a completely new approach would be the thing. Where accessibility is concerned I only have to think of Mac. People trying to map things to keys and shortcuts for ages and then they come along and now a blind friend of mine bought the new Macbook, becuase it has such a big mouse/touch pad. :-) Returning to music: The new mixes - sometimes - are very pollished, but that is a technology, that we didn't have before. Not in that precise a fashion and I rather like it sometimes. It depends on the style of music. But there are a few very interesting effects you can achieve with graphic timelines and visual EQs. Still, it would be interesting to think of other/new concepts to represent things in a totally non-graphical way. Warmly yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Robert! Well this thread is already no longer on-topic, that's why I renamed it slightly. :-) It really started with the iPhones. At least, there I noticed it for the first time. they only have their touchscreen, like many other smart phones nowadays. So apple released their screenreader VoiceOver. They use different gestures, like take two fingers and pull them down on the display ad the volume is lowered. You can use your finger to move across the full screen and read element after elemtn to you or you can activate a mode, where you can jump ahead to every next element. So they actually started getting fame from their phones and now they use the same system available for the notebooks. You can use the pad - as I udnerstand - to make your gestures and use the different modes to jump across the screen, find things, activate them and so on. there are many more ideas to make it easier. And I've heard, that more and more blind people change to iPhones or ipod touch, because they like it and can be very fast with them, if they have to be. It takes some learning, but it always takes learning, to adapt to an assistive technology. You always have to get to know the OS and then the logic behind the accessibility software. So I guess that's fair enough. :-) I never used them myself though. Not a mobile phone person and I can't afford any notebook, not to speak of expensive macbooks. :-) Anyway, a desktop is more reliable in the long run and can be more powerful. For the time being I'm happy to have no mobile system. Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello, Yes, some people are beginning to explore solutions to the touchscreen accessibility problems, and some people are even coming up with reasonably good ones: Apple are among them, and so are some of the android developers. I've never tried VoiceOver on IOS, but I do hear good things about it. Unlike Julien, after a period of resistance, I gave into the smartphone wave, and I'm fairly glad I did, since, for the first time, I have an extremely mobile set-up as a writer (Bluetooth keyboard and braille display connected to my Symbian phone running quickoffice). <shameless-self-advertising> If anyone would care to learn more about this, I started a blog a few months ago discussing some of the issues faced by blind people, on which there is an article about smarphones and their implications to us: http://inperspextive.wordpress.com/2010/11/26/getting-smart/ It's meant to be a three part series, and I intend to discuss some of the other issues which came up in the course of this thread as well. </shameless-self-advertising> Anyway, this thread has gotten way off-topic and it's probably time to drop the ball. But, to end on a positive note, I would like to add that general accessibility has vastly improved over the last couple of years, with things like VoiceOver built into all Apple products, Orca rendering most GTK/ATK applications accessible, and at least a bit of accessibility work being done on Andreoid platforms. It's only when one comes to specialised software, such as DAWs, that things fall apart. Cheers, S.M. On Wed, Apr 20, 2011 at 07:33:13PM +0200, Julien Claassen wrote: --

Hello Cal! Yes, that's also possible. Tat's I think how the Hexter CLI works. I guess even I should be able to copy from that code and generate sort of a CLI from that. Maybe I should take some time 0 in the next few weeks - and try to create a CLI for one of the other simple DSSI apps. Warmly yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Cal! No I didn't assume, that you could do it that quickly. But I don't know how quickly I can go about it. It sounds simple enough and from what I've read in Hexter, it didn't look too hard. But then there's me in the way. :-) Best wishes Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Massy1 Hm, why not something like Hexter, a shell. You might have different modes, which would represent sort of a tree structure only shorter. I think in the old graphic, you could open some "parameter pages" for certain areas of the synthesis. OK, that level would be purely UI centered and just allow for different commands to be typed and e.g. shown in the help or whatever. But I think it would still be the fastest way to touch it all. But for the time being, that's all dreaming. :-) Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Tue, Apr 19, 2011 at 10:10:29PM +0200, Julien Claassen wrote: You have a lot of parameters, also, you have different types (boolean, int, real, list, etc.). You would need an easy way to tweak these parameters and move from one area to the other (e.g envelopes to oscillators). Perhaps a shell/dialogue combination would work. Cheers, S.M. --

On Wed, Apr 20, 2011 at 12:34:24AM +0200, Julien Claassen wrote: Yes, we've agreed on this point before: it's a wonderfully flexible compromise, allowing what needs to be commands to be so, and what needs to be key-stroke controled to be so as well with minimal waste of time. Not sure, really. But aptitude, one fo the text-based dpkg front-ends handles package sections and subsections like a tree and allows one to expand/collapse branches and manipulate packages. Not quite what we want, as it relies entirely on keystrokes for actions, but an interesting interface. Mutt allows one to enter certain commands (mostly config) if prefixed with a colon. Seeing how long vi has been around and how many people use it, it's a wonder that its excellent interface philosophy hasn't been borrowed more often over the years. Cheers, S.M.

On Tue, Apr 19, 2011 at 08:24:55PM -0400, Paul Davis wrote: I remember, I tested it briefly, but it must have been at its inception or soon after, because it was too unstable to really do anything with, so I stuck with ecasound. Yes, tree structures, especially with coherent numbers can be very efficient. By the way, I believe this kind of interface design is not just useful for blind people, I'm sure a lot of users need to manipulate data as quickly as possible and don't necessarily want to muck about with the mouse. I just had this wonderful idea: what if parameters were searchable? For example, suppose one wants to change the envelope release time, one could hit "/" to bring up a search prompt and type "envel release" and hit enter, then the cursor would already be on the first matching parameter, if there were several matches, one could hit "n", just like in vi to go to the next match. This could significantly speed up the editing process. Cheers, S.M. --

Hi, Expanding/collapsing is an essential part of a tree structure, since it allows to speed up navigatioon. I don't believe the parameter search idea would introduce too much complexity, as the interface would already need to keep track of all the parameters in the tree. I quite agree about keeping the command and "visual", to use the vi terminology, interfaces fairly separate. Ecasound is a good reference for a command-driven interface, but I especially like the way nama has a "nearly" (we still have to review it) coherent set of long-hand and matching short-hand commands. Cheers, S.M. On Wed, Apr 20, 2011 at 10:55:09AM +0200, Julien Claassen wrote: --

Hello! So I finally went through the thread and collected ideas and thoughts. Here they are, a little chaotic still, but I suppose from there we can go on, adding to it, shifting things. Proposal for a good CLI access to audio (and other?) software The interface should have two parts: 1. a shell-like commandline 2. an interactive fullscreen mode Random thoughts: * Use a tree structure for commands/parameters * Have expand/collpase function for the parameter view (aptitude, mail-clients) * Parameters are searchable (the tree-structure is searchable for node-data) * Always move the real cursor (no soft cursor) to the actual parameter * Encourage programmers to use consistent long and short commands for the shell part * leave fullscreen mode by colon and enter by ESC Questions: * Which keys/mechanisms to use for collapse/expand? * How to move between parameters on one level? * What about real menus (as in file, view, edit,...)? * Can one assume, that OSC is always the easiest/fastest choice and hardcode it? * Would the commandline mainly just echo the fullscreen tree-structure? * Would the commandline hold special (non fullscreen) commands? I thought about a few of the questions and here are my tentative answers: * Which keys/mechanisms to use for collapse/expand? In alpine/pine the folder list (one major level of the tree) can be navigated by using the cursor (all directions). ENTER is used to access a folder (go down the tree). Only in the sublevels entries (mails) are listed one underneath the other. So cursor left goes back. Best to think of a different way, so one can have more compressed layouts, probably organise strongly related parameters in one row. For example Attack Decay Sustain and Release. * How to move between parameters on one level? Well partly answered. I think simple lists (showsn as such) might be very long seeing the amount of parameters Yoshimi has to offer. Or what do you think? It is a little more complicated than aptitude or some of the other examples, since they mostly use it for simple lists or long menus. * What about real menus (as in file, view, edit,...)? I think some real menus might occasinally be nice. It's just another tree with a root node, from which the main menus branch out. Might be reached by something like Ctrl+first letter or a printed capital. * Can one assume, that OSC is always the easiest/fastest choice and hardcode it? * Would the commandline mainly just echo the fullscreen tree-structure? If the command line does echo the full screen commands one might use a filesystem like navigation: ls - show all parameters on this level, probably with "/" after them, if they open a sublevel. cd name - change to level "name". get name - get current state, set name <value> - set parameter name to value. Perhaps some more symbols are needed to show things like sublevel, boolean, integer, float, string or list/enumeration. Perhaps get can offer that info. That way a lot can be done by the basic interface infrastructure, without the programmer having to worry about getting all the names correct a second time round. This would make some thing a little longer perhaps, but very consistent. Still shortcuts might be nice. Perhaps they can be implemented as aliases/substitutions: alias filter_res='set synth/filter/resonance' ? * Would the commandline hold special (non fullscreen) commands? Should one allow for it or wouldn't it be counter productive at this point? One idea might be to allow setting a whole level in one go. Good for setting plugin parameters. So you might do: ls effect/reverb room size reverb time bandwidth damping dry early reflection level tail level set effect/reverb 50 4.0 0.6 0.6 0 -18 -20 Another thing, which I'll enter into the file shortly: have a pager for the shell output, or at least allow to set one! So I ope, this doesn't seem too pointless or unorganised... Please someone pounce and make me see the errors of my ways. :-) Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

So if you view the tree as a virtual file system, maybe you could adapt code from Midnight Commander to use to edit parameters. And MC has the ability to accept CLI commands ... -- David gnome(a)hawaii.rr.com authenticity, honesty, community

Hi David! Hm, I've tried to use MC once and found, that it's interface isn't very helpful. Maybe it was jst me being confused. In any case, I think it would be easier in some respects to copy from aptitude or other such apps since they generate their tree structures based on internal data, rather than a real filesystem. Still, perhaps worth it, when the time cometh. :-) Good thinking! Best wishes Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Thu, Apr 21, 2011 at 01:04:06PM +0200, Arnold Krille wrote: Maybe a virtual filesystem wouldn't be the most friendly environment to control OSC parameters from a user perspective. But then it might be for all kinds of utilities that could be build around this. lieven

Hello! Arnold: Interesting idea. I suppose it could be used for other purposes. But that would have to be a single app, a daemon and I'm not sure how friendly the FUSE API is. But hell, it's a nice one! David: As I remember, I had problems with the cursor tracking in MC and the screen held too much info. I think it did some panelling or output a table. I have to recheck. But basically it's the same mechanism, it's just a question of: How friendly is the original to blind people, or how easy is it to adapt. I mean there can be apps, that do that sort of thing and have some great features, but are inaccessible or bad in other ways. Still you might take up features. That's why I chose aptitude, theyare very good about cursor tracking (hard cursor motion). Warmly yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Will! Not sure how exactly error reporting is handled. but with hirarchy I just meant the fact, that you have paths and that those paths are typicaly chosen to reflect some kind of hirarchy. So you have: /params/addsyn/volume and not just: /volume1 /volume2 that is more of a usage thing, but the question is, do people have an understanding about that sort of thing and use the paths to reflect actual hirarchy, as it is suggested by the engine, whatever it might be. Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Thu, Apr 21, 2011 at 08:32:31PM +0100, Folderol wrote: Then again, with full search capability on parameters, one could easily enter the full line as described above and be taken directly to the node, bypassing the hierarchy. The hierarcy is there for convenience, but searching is always there, so one never needs waste time trying to locate anything. Cheers, S.M.

Hello Massy1 First to the FUSE part; It might be interesting, but on the other hand, we already have lo_send, I think that was the programs name, which just sends a parameter value to a specific OSC path. I've used it in my earliest testing with DSSI plugins. You can use that from a shell script. By using this design for our interface, we only add another layer. In any case i'm not sure how much info OSC nodes can actually give. I would doubt, if they can tell you what unit a value has or what its possible enumeration values mean (1 = sine, 2 = sqaure...) So that part would always have to be configured in some way. If one is clever, one might write an xml file for this. It's not as much work as hard-coding it into a single interface for a sngle program and might allow for an "almost" automation. Without that XML file, the UI would just show, what can be gathered from the OSC parameters, through the OSC system. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Thu, Apr 21, 2011 at 10:26 PM, Lieven Moors &lt;lievenmoors(a)gmail.com&gt; wrote: i think that its unfortunate that this paper is not more widely known: http://cnmat.berkeley.edu/system/files/attachments/osc-query-system.pdf

Hello Lieven! IO wasn't ask, but I'll chip in a penny anyway. :-0 I just had an idea the other night: Why not use the RDF format to describe the OSC parameters? Isn't that, what RDF files do for plugins? Describe their parameters (ports), so that hosts (like Ardour) can generate nicer GUIs for them. Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Lieven! Good idea. I could ask on LAD and Csound, since they have some use for OSC. At least it's been there for years and I'm sure people use it. Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

----- "Lieven Moors" &lt;lievenmoors(a)gmail.com&gt; wrote: no

Hello, Sorry, been away for a bit. Leaving the question of the interface itself aside for the time being, it seems that the most crucial thing is to come up with a way to gather, sort, and define the exposed parameters in a manner as flexible as possible and as painless to developpers as possible. One question which hasn't been answered yet, I think, is that of whether OSC is the best way to control sound engines and how well it is supported at this point. If so, then we can focus on OSC and its peculiarities and we needn't keep the interface and the generation/control mechanisms separate. I mainly liked the FUSE idea because I thought it could be useful as a means to separate the interface from the generation/control part, thus allowing our interface to drive, not only OSC-enabled applications, but *any* kind of application capable of generating a FS hierarchy, be it inlined or through any third-party protocol. If we focus on OSC alone, then this becomes an extraneous and likely tedious step. Otherwise, Julien's idea of a standardised way of describing parameters, be it through XML, RDF, or any other structured format would be the ideal way to go about it. With suitable tools to generate this file, even a non-programmer could easily help produce a working interface. Not to mention that such a file could be used to create alternate GUIs, just as much as text, or even FUSE based ones. This is largely a synthesis of this aspect of the discussion so far. Any thoughts? Cheers, S.M. --

On 28/04/11 07:08, Julien Claassen wrote: Just a couple of thoughts from the perspective of the "bear of very little brain" behind yoshimi: - the FUSE idea isn't entirely without merit, but I really don't want to know about it in terms of implementing anything along those lines within the synth - OSC is "loose" by definition. However desirable, the notion of "one spec to bind them all" is doomed to fail. Every second developer will encounter enough exceptions in their particular app to justify non-compliance. - one of the many links floating by in previous discussion was <http://idmil.org/projects/mappingtools>. I haven't looked into those tools closely yet, but just reading the blurb gives a good idea of the problem space in play here. There will always be a need for mapping the OSC control set of one app or device to the control set of the app or device being controlled. - strictly speaking, RDF isn't an XML format. XML is just one of a number of data formats supported by the RDF libs. Last year I went through the tedious exercise of converting yoshimi to use turtle format fot it's data storage (via raptor) instead of xml. State of health plus the sheer scope of the testing exercise led me to put all of that on the "Not now!" shelf. Some of that work looks like being recyclable when it comes to putting OSC control into yoshimi. That's all I can think of for now. cheers, Cal

On Thu, Apr 28, 2011 at 08:23:42AM +1000, cal wrote: Hi Cal, I was wondering how easy (or difficult) it would be to implement OSC support, based on an RDF mapping. It's just a hypothetical question, but I was thinking if an RDF mapping could be made that could be used both by the application developer (to automatically generate an OSC-to-function mapping) and the OSC interface designer, which could use the RDF to generate an interface based on those mappings. Could such an RDF be a win-win for both? Just a thought, lieven

My idea behind the FUSE thing was that it would allow easy editing via non-GUI text methods, since a lot of programs (such as Midnight Commander) already have code to navigate file system trees and edit nodes, which is what Julien was looking for. Sounds like some are moving this way beyond what Julien was originally looking for: a simple non-GUI way to edit Yoshimi/Zyn synthesizer settings. S. Massy wrote: -- David gnome(a)hawaii.rr.com authenticity, honesty, community

Hi Julien, I was reading about RDF myself a little. Although it's quite a long read, this link seems like a good starting point. http://www.w3.org/TR/rdf-primer/ After reading most of this, I think RDF and OSC would make a great match. I don't think standard rdf would provide all the necessary types for OSC though, but it should be possible to make rdf schema for OSC. (I don't know how that works yet, so I should read up on that too). LV2 might be the thing to look at as well, because it does all this stuff. But it also uses OWL which is an extension to RDF. I think it is mostly used to provide a more object oriented approach to RDF, and it complicates things quite a bit. (what does ontology mean again? :-). But it might not be nessecary at all to use OWL in this case... Well, I'm not sure how all this should be done in practice. Just wanted to share a few of my first impressions. Greetings, lieven

Hello, This discussion is very interesting and new thoughts keep floating up to the surface: it's very refreshing. I too will have a look at RDF and see what I think of it. It seems clear to me that a means of describing parameter sets is really the corner stone to lay before achieving any of the things discussed so far in this thread. I like the idea of a plugin architecture that would allow the interface builder to interact using various protocol, but, at the same time, I'm pretty sure such an architecture is way beyond my modest programming skills. Same goes for an OSC-to-function generator. I think starting simple might be3 the best way to hopefully achieve something useable at some point in the future. :) Cheers, S.M. --

Hello! I agree, it will be best to start with something small, but we should think about the big picture, so we at least create a structure, that can accomodate the big library. As to a testing case, I suppose we can start, with something, that is already there and use one of the DSSI synth. In the basic DSSI package there are some test cases and they have there OSC sets. Advantages: they are small, tested, known to be working and designed from the start to be controlled via their OSC interfaces. I think that's what all DSSI UIs do. But a good question there: what does the synth developer have to do? If we strip it down to the very basics: It should be expose parameters over OSC. If possible in a meaningful way (have nice paths and good names). If the synth developer is a kind person he also writes a description/mapping file. I think it would be enough to know the task and type of each parameter, the rest could be filled in by a volunteer. It shouldn't be dificult, since at that point it doesn't require creating structures, but just filling in good paths, if they don't already exist. If we think about some kind of standardised way to generate the synths OSC interface from an RDF file or whatever, that should be sepearted after all, since some synths/apps already come with their OSC interface, which has been there for some tme and maybe other apps already rely upon it. But such a code generator thing can only be done, if we are clear about, what we want and need and what is feaseable for an engie developer. So I think this can really be moved towards the distant future. Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Fri, Apr 29, 2011 at 08:04:18PM +1000, cal wrote: [...] Simply put, some access to the parameters, and some description of those parameters in terms of name, group, type, and range. [...] You're quite right there. My initial thought was simply to hack together something to tweak existing yoshimi patches in non-realtime; I think we just got very excited when you mentioned the possibility of exposing more parameters through midi. I think such mechanisms as were discussed in this thread could be beneficial, not only for the creation of alternative, accessible interfaces, but for interface-building in general. This said, a complex engine such as yoshimi undoubtedly is, probably isn't the best place to prototype these ideas. As Julien pointed out, a much simpler DSSI synth probably would be a far more logical starting point. *chuckle* I think it's best to go with the flow here and focus on what *you* as the developer are working on. So, for instance, you talked about exposing parameters to midi controlers. Perhaps there could be a structured text file where one could assign mappings by hand, so that one without access to the GUI could still benefit from this. Perhaps a simple OSC interface allowing to load patches and midi mapping files, as well as save modified patch files could be created. That would already be a giant leap forward for us in terms of useability. Cheers, S.M.

Here is more on the parameters-in-filesystem idea: On Friday 22 April 2011 00:31:39 S. Massy wrote: To load and save the settings, just write/read the file "settings" or use it for cp. Multiple UI's would be possible, even signaling of changed parameters will work through the inotify system. Scripting will work, for automation you would have to decide whether the parameter is changed once a valid value is written or just after the "file" is closed. You could even define "files" for stream input/output but that part is better left to jack. I don't think remote control over network will be possible by this as fuse- mounted dirs afaik can't be exported via nfs/smb/cifs. But you realize that this is all actually OSC with a standardized introspection-method? - One could write a generic OSC-fuse-bridge if only there is a way to tell that bridge what to create or how to introspect the (remote) apps. - One could write/use a simple set of text-tools to introspect/get/set OSC- paths (like the qdbus/dbus-send/dcop-tools). Going for real OSC would also add the network-transparency for free. Only advantage of the FUSE-bridging is that its more like plan9 (everything is a file). Have fun, Arnold

On Thu, Apr 21, 2011 at 10:40:14AM +0200, Julien Claassen wrote: Hmm, maybe calling them classes was misleading, since I didn't exactly mean it in that way (with methods etc.), but rather was seeking a non-specific to talk about these concept. [...] Perfectly correct. I see them as being separate. Key definition would vary according to the type of parameter being manipulated. The handler should also display critical information about this parameter in a straightforward manner. Something like: "Name: OSC1 Freq, unit: Hz, range: 20 - 20000, Value: 900" "Name: WaveForm, Type: List, 1. sin, 2. tri, 3. sqr, 4. saw, Value: Saw" There should always be the option to input the value directly, bypassing the decrement,increment keys. What use-case do you have in mind? I realise it's ambitious, but I see a possible design goal for our dream-interface as being able to populate itself, thus offering a convenient, mostly toil-free way for developers of audio software (I mostly have synths and plugin hosts in mind at this point) to offer a text interface. See my reply to the FUSE idea further down this thread to get a feel of how crazily I'm dreaming right now. :) Cheers, S.M.

Hello all1 Just a note on the side: Please could you stop including the original messages at the top, unless you want to respond "inline". I know what I said and I'm sure so would everyone else. Otherwise all the mails are there or included at the bottom of the mail. I'm not asking out of bloody-mindedness, but it is tedious to find the relevant message that way, because I expect something somewhere in the quoted message. It's not that easy to spot sometimes. Remember: I have to look at every line, at least shortly, so would Massy. Thanks and kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Lieven1 the tree view is still nice, because it allows for easy one-hand navigation and looks more interactive. Of course you can do all that on a commandline, but it requires learning things directlyfrom the start. Where a browseable tree allows for going along and browse. :-) Besides, commandline commands might be a bit long, as was pointed out before. I do like the idea about i and o though. Automatically generating interfaces from OSC command sets. I'm not sure. I know, they have what they call paths, but I'm not sure how hirachical they are. I believe one should be able to query the type of an OSC parameter/action/command, whatever they are called. So that goes part way to automating things. Anyone, who really uses OSC here, knows about that? Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Cal! Hm, I believe that might be partly helpful. I have to read more. Otherwise I might just have a look at the liblo pacage. I had that in mind all along, but thought someone had some direct, first-hand realworld example experience on how structure in OSC paths is carried. Never mind, I'll do the RTFM, do not enough of that anyway, usually relatively lazy about it. :-( Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Fri, Apr 29, 2011 at 1:41 PM, Julien Claassen &lt;julien(a)c-lab.de&gt; wrote: I think that you've failed to read the URL i posted a week or so ago. There is already a tentative standard for discovery of an OSC namespace, and liblo already supports it. http://cnmat.berkeley.edu/system/files/attachments/osc-query-system.pdf

Hello Paul1 so I've read it. One basic questin arises: Is the exploration supplied by liblo itself or does the server have to supply it somehow? I couldn't find something in the liblo docs yet and I tried it with hexter and got no results or wrong paths. :-( The documentation has to be dev-supplied obviously, but what about signature and return-types? Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Paul! So the complete exploration of structure, signatures and documentation is relying on the developer of the OSC-responder/server? Are there libraries, that make this task easier for the server/responder developers? It's a nice feature, but I suppose, that many developers won't see a good use for it. At least not as good and frequent, that they would like to put in the wor this takes. I imagine to do this all by hand, involves creating a tree structure for the OSC commands in your app and store all sorts of data in the tree nodes. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello again Paul1 In which version of libLo did Namespace exploration appear? I tried it using oscsend and hexter, my liblo version is 0.26 and everything was built with that. Did they change the syntax? I used: oscsend localhost 11566 /dssi/hexter/hexter/chan00/ On the Hexter console I just get a warning from jack-dssi-host (or hexter itself): hexter channel 0> jack-dssi-host: got unhandled OSC message: path: </dssi/hexter/hexter/chan00/> Sorry if I'm thick in the head here... Kind regards Juloien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Lieven! Thanks for the tipp. I'll look into that. After I've got your program and it sounds, like it will be a very nice example in deed. The documentation and return-type and signatures aren't dificult, it's just another simple path, appended by the required command: /path/to/node#documentation At least, if they didn't change it from the proposition made in the small paper Paul passed on. Only slight problem there is, that one has to write the documentation oneself and I believe, that the other commands have to have some kind of server/responder developer involvement as well. But let's start small. I suppose - from what I've seen - extending the simple osc_server example coming with liblo is easy to test these. Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello again! OK, there's the point where I give up. At least for the moment. I've uploaded a small tarball on my server: http://juliencoder.de/osc_test.tar.bz2 It contains Lieven's modified program, the modified liblo example server and the paper on OSC querying in HTML format. I think, I've just seen my error. I need to write a different method to receive documentation and be sure to do it in teh format expected: (ss) path, doc_string Hm, probably I'll give it a try. Small question: I've read, that liblo doesn't handle pattern matching? Is that still true? Kind regards and thumbs up :-) Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On 04/05/11 07:09, Julien Claassen wrote: The lo_server_add_method() function explicitly prohibits the '#' character (and others) in the method path, so I figure we'll need to parse or pattern match the '/xxx/yyy/#documentation' request in the root/catchall method. cheers.

On Tue, May 3, 2011 at 8:17 PM, Lieven Moors &lt;lievenmoors(a)gmail.com&gt; wrote: [ ... ] one warning: as you get deeper into this, you are going to run into one of the more unfortunate aspects of OSC: it is really deeply unsuited for use as a 2-way protocol. That is: it works very nicely when you have a controller that wants to send a message to a receiver, without expecting a reply. It works very nicely when you have an "engine" that wants to distribute information on its state to someone who is listening for such changes. But it really starts to break down if you use it for the "send a message and get a reply". Its not that it breaks down in a deep and fundamental way, more that it becomes unreliable and requires another entire almost-a-protocol-itself layer on top of OSC to ensure that you actually collect the replies etc. etc. It gets even more complex if the ordering is important.

On Wed, May 4, 2011 at 9:38 AM, Lieven Moors &lt;lievenmoors(a)gmail.com&gt; wrote: there are two issues. one is the issue of UDP not being "reliable". the other is that OSC messages have no serial number on them. if you end up sending the same request twice and get two different responses, you have no idea which one actually came first unless you simply don't use a reliable transport layer. in that case, the one that arrived first is the response to the earlier request. but now you've got an unreliable transport layer. if you're using OSC with UDP transport, you have absolutely no guarantee of this. of course, if you are working with a wired LAN, this is really deeply unlikely to be an issue. but move into a wireless LAN let alone WAN configurations and the possibility that a UDP packet will simply fail to arrive gets high enough that you do have to take it into consideration. the simple answer, of course, is to use OSC over TCP which I *think* liblo can do (and if it can't, it should be easy to make it). but this still doesn't address the ordering issue, because OSC itself has no concept of serial delivery (or even time).

I'm reading this again... Wouldn't this apply to UDP then? (as unreliable transport layer) lieven

Hi, This is interesting; however, I wonder whether it is really relevant to the problem we are trying to solve here. As I understand it, we want to: * Get a list of parameters from the engine in order to populate the interface. * Send parameter changes to the engine. * Listen for parameter changes and other events coming from the engine. There is two-way communication but it does not closely depend on an action-query-response-query-response-action sequence. In other words we are using both schemas Paul described--- sending control events and listening for external events--- without both really needing to be closely linked. Or am I misunderstanding something? Cheers, S.M. On Wed, May 04, 2011 at 09:53:59AM -0400, Paul Davis wrote: --

Hello Lieven! Oh, so I made a programming mistake somewhere along the line, since I didn't want to send "//#documentation" but "/foo/bar/#documentation". I will look again and put in some more debug messages. :-) Thanks for all the rest of the info. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello! First of all it was interesting to follow your discussion about the issues with OSC. I think we ca - for the moment and typical use-case - skip the considerations of wireless LAN and transfer over real network cables, since we are mainly focused on controlling apps on one computer. Of course, you can extend this concept, but since TCP is no problem, that could be arranged. OK, Lieven, writing a server, that can respond to all the "commands' might take a bit, sice I think, I'd much rather write it in C++ and with a proper tree structure. I found, that string processing is easier in C++ and storing the necessary data might be clearer from a readability point of view. The problem I see - at the moment - is processing those commands, finding them in the paths. I could grep for "#command" somehow, but again I feel C++ string class suites me better for tat purpose. Since it's Uni, don't rely on me being quickly. I'll find a suitable tree structure, most likely one from the boost library, just so you're warned. :-) And then I need to do some experiments on strings. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On 04/05/11 06:51, Julien Claassen wrote: There is a function in there, but I haven't got close to trying to use it yet - int lo_pattern_match(const char *str, const char *p); cheers.

Hi Julien, I had a look at the query capabilities of OSC, and I started writing a small program that queries a certain client for all possible OSC paths (terminal nodes). I see it as a first little study for the program you want to make, but it might become quite useful in it's own right. Later I'll have a look at how to return type-signatures and documentation as well. You can get it here with git: git clone git://gitorious.org/osc_query/osc_query.git osc_query you can use it like this: ./osc_query -p [port] And it should print out a list of paths for the app on that port. It's just a start, but I hope you'll find it useful as an example... Greetings, lieven

Hello! I started programming, but come up against a question. There my stupidty and practical inexperience comes in. How to send a reply to say a #documentation request? And do I use the format as specified in the osc-query-system papaer: #reply (ss) /path/requested, "this is documentation" Or do I need to quote the path as well? Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Cal! I'm not currently worried about that, since I'm starting small. The commands don't have parameters, so I can just send strings Building a blob shouldn't be too dificult, there is a function lo_blob_new or something, tat can help. But I'm worried about the basic format. Should I quote all strings? Is the message format, that I gave basically correct? Which function do I use to send the reply? Or is the extra info just stored in some liblo structure and later handled automatically by liblo, like the namespace exploration? If I find answers to these questions, I can manage the rest, I'm sure. Normal outside value manipulation isn't dificult, I can look at the example server. Basic storage doesn't seem to be a problem, now I used boost::any and the boost::ptree looks exatly like the structure I've been looking for and I'm rather sure, that based on these I can write a lo_handler, that can deal with all the requests. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hi Cal! Thanks, I never thought of looking at the actual sources of the library. :-( Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Lieven! Thanks, that makes a lot of things clearer. Just to be sure: client: lo_send(server_address,"/foo/bar/#documentation","",NULL); Sever: lo_send(client_listener,"#reply","ss",data); So if I can construct the correct data, then that's it and I suppose I have to use lo_send_from on the cient side, so the server knows, where to send the reply. I'm on it, thanks! - though perhaps in the evening, it's so beautiful outside now. :-) Warm regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Massy! I suppose it is really best to start with the osc_server supplied with liblo, since it just outputs messages. If afterwards, we feel confident enough - meaning me, I suppose Lieven is - then we might tackle hexter, since it has a text-UI, where you can recheck. It accepts program/bank change, quitting (without parameters), show, hide, control and configure. No idea, what they do, but I seem to remember, that the code was cleanly written, so it should become clear, at least the parameters. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Tue, Apr 19, 2011 at 10:05:18PM +1000, cal wrote: This is the way to go IMHO and I wish more developers would adopt this philosophy, as separating the UI from the engine means relative ease in terms of creating new UIs or even controling the engine from other applications. It also solves the problem of accessibility at the same time. For instance, LinuxSampler doesn't have a command-line interface as such, but its simple network-based protocol makes it extremely easy to send "scripts" to load libraries or change the way the sampler behaves. Cheers, S.M. --

Hello M.! Yes I suppose, that sed and awk might do a nice job of it, but you'd have to write a pretty big and complicated script. I'm not against sed and awk, they are a kind of magic and they work wonders. They might work for the time being. But in general I suppose, that some kind of c/c++ program might be better. Still thanks for the suggestion, as I said, it might do for now. Warmly yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de