plasq.com

plasq forums

home | help

Post a new message in "Ideas"

Name:

Subject:

Enter code shown: *:

This helps us prevent spam.

I can't read this, show me another one.

topic icon:

boardcode:

Colour: Size: Close all tags

Message:

emoticons

Select Image file to attach

Select file to attach

Topic History of: Macros and Scripting...
Max. showing the last posts - (Last post first)

Author	Message
songcarver	ok, quotes are getting out of hand..so I'll try to keep this short RE: re-tuning a guitar on the fly.. I once saw a show on TV (10 years ago..) where they talked about a new guitar which had motors attached to strings, and had computer controlled tuning. you could press a button and viola! new tuning. but it did take a few seconds. Phillosophically, I think tuning by ear is still better than by machine..it makes you really listen, and also makes you realize that 'tuning' on a guitar is flawed anyway, it's equal temperament. By re-tuning, do you mean "drop D" type alternate guitar tunings? or tuning other than equal temperament? In the former, I'd say it would be better to then realize you need to learn how to voice better. In the latter I would say you could possibly bend each note to get the effect you are after. I will say at this point that it is very cool that you play a stick. I know what you are saying though. Neccessity is the Mother of invention, i say, so what exactly do you need to do? RE: "an interface that knew what you needed to do before/while you were doing it. " I think thats a common error. We actually don't need a smarter/ more intelligent tool, we simply need a BETTER tool, a tool that becomes more like an extension of us. Or, it could be the basis for a Plasq next-generation hardware controller. Huuuuge evil grin RE: The intelligent collaborator... that concept has been around for a long time, and the means to do it has been around a long time as well. So why hasn't it taken off? I suspect because it's the wrong metaphor. We are physical beings. Lets look at the example of looping-control by changes in volume. Here we are forcing stylistic decisions on the music, that is, you must stop playing before you want to loop. And also, we are playing the decision into the hands of a machine, instead of allowing me to make a decision easier. An idea I have thought about...I mean, we don't even need to press 'start record' really. We could just have a really big sample buffer. And at any point just say "loop the last 4 bars i played". I really do appreciate your comments mech, and there is a lot we can do with timing etc. Hopefully we are getting somewhere here!
Mech	songcarver wrote: Well, I appreciate the time and thought put in to this one Mech, but I've got three key points here: 1) One of the important things in musolomo is always having the musician involved as much as possible.. I think one of the big flaws is to negate how important actually physical doing (no matter how menial) is important to the soul of music. No argument there. However, there are times where the menial tasks (button presses) take up so much of your conciousness that it's impossible to concentrate on the music. That's what I'm trying to alleviate here. If there's a particular pattern or sequence of functions that is so complex as to be completely all-consuming (yet is mundane and repetitive enough to not be a "creative" aspect of the performance), then why not automate it? Here's another (somewhat flawed) example. For years, guitarists have been struggling with alternate tunings. It's hard enough to re-tune a guitar between songs, but what if you require a different tuning between the bridge and chorus of the same song? That's nearly impossible; switching between two differently tuned guitars is about as close as you're probably going to come to accomplishing this. I'm sure you'll agree though, that the actual process of tuning and re-tuning the guitar has absolutely nothing to do with the quality of the song itself. Yet playing in that alternate tuning could very well be the one thing that gives a song its own special character. So, to bring it back around to Musolomo, I'm merely wondering about automating those complex functions which would otherwise get in the way of the musical process. 2) It seems perhaps the big problem you are coming across is 'trying to control so many functions with only 10 fingers'. The main point here is that most music technology is terrible. After all, it has no feedback visual or haptic, it cannot sense if you are touching a knob or not, and we are still talking 'knobs'... what a poor excuse for an interface. We need to solve those problems and stop making workarounds Agreed. And in my case, I'm playing processed Chapman Stick. With all ten fingers already on a fretboard, my own personal problem is actually "trying to control so many functions with only 2 feet". You get similar issues with computers in general, though. In fact, I can remember one interview with either Jobs or Wozniak where they were touting the need for an interface that knew what you needed to do before/while you were doing it. So, if you sat down at a computer and just began typing at the keyboard, it would automatically bring up a text editor and begin putting what you started typing into a formatted document. Yeah, they're still working the bugs outta that, I think. One solution, for our purposes, is to try to figure out how people use the software (unfortunately everybody's different). Trigger record is a good start. However, what if you could code in conditionals, like using a threshold to start recording, then listening for a particular event (like falling below the threshold level for more than, say, two beats) to stop recording and automatically start playback on the next bar division. To be fair, there has been a lot done on the hardware side to stretch the existing MIDI spec. One of my controllers is a Peavey PC1600x, for instance. This thing will mow the damn lawn, MIDI-wise -- buttons, sliders, foot control, key remapping, and full sysex support. However, there are two big things missing from its features. First, it won't operate in 4-D. In other words, there's no way for it to take timing into consideration; you can't have it send out commands at specified intervals. Second, there's no developed conditional structure. There's no facility for constructing an "if-then" sort of relationship within the datastream. Even the most advanced MIDI controllers can't really do these things, so it's left up to the computer program to interpret the data and make whatever decisions are necessary. Again, some of this might be possible within Musolomo with a rudimentary scripting function built in. Or, it could be the basis for a Plasq next-generation hardware controller. Huuuuge evil grin 3) If you really want to script some part of musolomo, then you could probably go a LONG way with midi clips in Live Yeah, but (devil's advocate speaking here) what if you're using Musolomo within Rax. Okay, okay, don't thwap me; I get your point. I'd considered this as one possible workaround, but thought that the potential of internal scripting might very well open up areas beyond what MIDI clips were capable of. I am posting this over in the "mad science" forum, after all. The MIDI clip solution would also make it a bit harder to implement a user library -- and likewise help promote a user community -- especially when the MIDI clips one user puts together might very well have a completely different MIDI mappings than another user is using. Ultimately, you'd like the software to eventually reach a point of intelligence where it can make decisions based on complex conditions, such as routing only notes played between C2 and C3 to be recorded into a sample (I don't even want to begin thinking about having Airy code that pitch discrimination algorithm). Beyond that, the holy grail is a feedback loop with the software making decisions based on your playing, and with you making decisions based on the software's decisions -- a reasonably intelligent collaborator, if you will. That's probably something more fitting to Max or Bidule than Live (although Live's 'Follow Actions' are a step in the right direction). All told, it probably wouldn't be a bad idea to host a collection of those MIDI "macros" in lieu of an actual scripting function, but a few tutorials sure wouldn't hurt as well. But we do appreciate the idea Like I said earlier, thanks for listening! Even if nothing I suggest ever gets implemented, I'll be happy if the discussion merely spawns the germ of idea that then spawns the germ of another idea that eventually helps implement a useable feature. Whoa, getting late here -- better crash. TTYL, and thanks again! --m.
songcarver	Well, I appreciate the time and thought put in to this one Mech, but I've got three key points here: 1) One of the important things in musolomo is always having the musician involved as much as possible.. I think one of the big flaws is to negate how important actually physical doing (no matter how menial) is important to the soul of music. 2) It seems perhaps the big problem you are coming across is 'trying to control so many functions with only 10 fingers'. The main point here is that most music technology is terrible. After all, it has no feedback visual or haptic, it cannot sense if you are touching a knob or not, and we are still talking 'knobs'... what a poor excuse for an interface. We need to solve those problems and stop making workarounds 3) If you really want to script some part of musolomo, then you could probably go a LONG way with midi clips in Live But we do appreciate the idea songcarver
Mech	Argh! That last line should read "Please ignore the multiple "ul"'s and "/ul"'s in the examples."
Mech	Okay, side note: I've just discovered that the "Preview" function of the forums here will support multiple nested unordered list tags. Unfortunately, the actual posted message won't support it. So, while those code examples were formatted quite nicely as I was previewing them before the submit, they're somewhat messy now. Please ignore the multiple 's and 's in the examples. Grrrrr.
Mech	Here's an idea I've unabashedly ripped from Jeff Larson's Mobius VST. Still, it's a good idea, IMNSHO... With any effect, one eventually finds an instance when they just don't have enough fingers (or feet -- for those of us using foot controllers) to hit a button sequence in the proper order as quickly as we'd like. This is especially poignant with most software and VST's, since the interface is usually through a mouse and computer screen. Credit where credit is due, Musolomo does a great(!) job of opening itself up for external control, but nothing's perfect. If it were possible to code macros -- multiple commands linked to a single keystroke or trigger -- then things get a lot easier. Now, I do think there's already a possibility to kludge this in a very basic way using existing functionality, by assigning multiple functions to a single external controller. However, the real fun starts if you put together a scripting function inside these "macros". Let's say that you want a loop to repeat three times forward, then reverse itself for one iteration and start again. That wouldn't be impossible using keypresses, but would be complex enough to be a real pain. Instead, you might put together a script that looks something like (code comments are between "/" and "/"): macroname="reverse4thbar"; /define the macro/ [ul]function {get $keypress}; /assign samples as they are played/ foreach $keypress; [ul]while noteon=1{; /repeat this pattern as long as the sample plays/ [ul]loop iterations=3; /play the loop three times/ reverse; /reverse the loop/ loop iterations=1; /play the reversed loop one time/ reverse;} /reverse the loop back to normal/ end; [/ul][/ul][/ul][/ul]So here, as I said before, you'd fire off the macro, then any sample you triggered afterward would repeat as normal 3 times, then would loop reversed once, then 3 times normal, then reverse, etc., etc. I'd also imagine that there would be another function to affect only the first keypress after the macro fires, rather than all of them. (Aside: sorry for the kludgy C-like syntax. I never actually got much beyond printf{"Hello World!"}. Hopefully you get the idea, though.) Or, here's another example, using a hypothetical argument for "duration". If we assume 24ppqn (parts per quarter note) for a sequencer resolution on the host, we can then beat-sync the following functions. macroname="triggergate"; /this section is pretty much same as above/ [ul]function {get $keypress}; foreach $keypress; [ul]while noteon=1{; [ul]quantize on; /sync actions to beat or bar/ play duration=24; /remember, 24ppqn=1 quarter note/ mute duration=24; /mute for one quarter note/ unmute duration=24; /unmute for one quarter note/ mute duration=24;} /mute for one quarter note/ end; [/ul][/ul][/ul][/ul]In this one, the sample starts, plays for a quarter note, mutes for a quarter note, plays, mutes, plays, etc., etc. So, you've got beat-synced trigger gating self contained within Musolomo itself. Similarly, you could sequence entire strings of functions in time with the host sequencer. I'm fully aware that the syntax (not to mention the coding) of the examples I've given is buggy, to say the least. However, I hope it gets my point across that a macro function and, even more important, a scripting function would add tons of extra features to Musolomo that the users could then code all on their own. In addition, it would allow you to open up a user area where fans of Musolomo could post pre-canned scripts for different functions. The userbase itself could help expand the functionality of the product, and those users who didn't wish to code their own scripts would have a resource to easily pick-and-choose which functions would work in their own environments. --m.

Joomlaboard Forum Component 1.1 Stable
Two Shoes M-Factory