Hi list,
It is 2 weeks (more or less) since I started using pd... It is easier than I thought, though, looking to other people's work, I reckon that I have a long way till I built my instruments for music making.
Anyway, I have attached my first instrument here. It uses a sine osc and can be played via the keyboard's numpad (1-8). On load you have a c minor harmonic scale loaded but you can switch to minor (upwards) melodic and major scale via 3 message buttons. Using numpad's 9 and .(del) keys you can switch octaves. Using the a,b,c,d,e,f,g keys, you can transport to the omonymous scale. Using the 0 key, you mute the instrument.
Not quite much, but it is a begining...
Any advice, or guidance will be highly appreciated.
Regards,
Terumi
ΓñçóéìïðïéΓ₯ΓΓ΄Γ₯ Yahoo! ΓÑñΓ₯Γ¨ΓΓͺÑôΓ₯ ôÑ Γ₯Γï÷ëçôéΓͺà ìçΓΓ½ ìÑôÑ (spam); ΓΓ― Yahoo! Mail ÀéÑèΓΓ΄Γ₯Γ© ôçà ΓͺÑëýôΓ₯Γ±Γ§ ÀáΓÑôà ðñïóôÑóΓΓ‘ ΓͺÑôà ôùà Γ₯Γï÷ëçôéΓͺþà ìçΓáìΓôùà http://login.yahoo.com/config/mail?.intl=gr
For some reason I can't get it open at the moment, but I wanted to say your next step could be a qlist or something to record and playback songs.
On 7/24/06, Tas Pas tprotopgr@yahoo.gr wrote:
It works exactly as you describe, nice start into Pd. The only gripe is that you use number boxes as temporary storage values. I think this is frowned upon because it can slow down the patch depending on the graphic capability of the machine if you update them. The "better" method is to use ordinary float boxes and if you want to see what values are there connect numbers only as displays (ie not in the control signal path)
On Tue, 25 Jul 2006 00:04:53 +0100 (BST) Tas Pas tprotopgr@yahoo.gr wrote:
On Tue, 25 Jul 2006, padawan12 wrote:
Yes, that's one reason, and another one is that because it biases your patch toward one way of visualizing your data, meaning that if you want to see your data otherwise, you have to use two ways of visualizing your data, because one is hardcoded in the patch.
In most any case, any abstraction which is not itself a visualizer for another abstraction, should have inlets/methods for setting data and outlet(s) for getting data, whereas anything aimed directly at the user is purely optional and would be better off being a separate abstraction.
I like the concept of a non-GUI object being two-way-connected to a GUI object, or else a GUI object containing a non-GUI object acting as a user-oriented wrapper for that non-GUI object. The first of those two options is more flexible because the non-GUI object is not hardcoded, so the GUI part can be used with different non-GUI objects, provided that the non-GUI objects follow the same conventions.
(non-GUI vs GUI objects is also often called Model vs View.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 7/25/06, Mathieu Bouchard matju@artengine.ca wrote:
I've wondered about this first way. Would you need a [change] object or something, though, to keep from starting a loop? Or a [set $1( message? -Chuckk