up for a challenge?
Been trying to figure this out for a while with no luck.
Its an attempt at making an abstraction which is similar count~, tap.count~ etc… but unlike those, is turned on/off at signal rate and also has it’s length/count modulo set at signal rate.
The patch is commented if anyone feels like having a go!
I’m out of ideas.
(it’s a little annoying that count~ and co are not fully signal controllable already, as they seem to be made for use when accuracy is important)
----------begin_max5_patcher---------- 1472.3oc0ZssaaiCD8YmuBVCTfVrNIh5lsVf.r6a69MrsXAsDsMajHMDoZiS Qy29NjTxQwwNQhwVNadP1RhWNygCOyLz4mWLZ7bwcT4Xzui9GznQ+7hQiLOR +fQ02OZbA4tzbhzzrwb5ODy+13I1Won2oLONcEguj9Pyy4UEhJUNUY5Dt9oq IpzUL9x+sjlprSZ.N5JuIHeOyGQSs2bkG5q08wNLpMqo1NLVxVxI4i21fEBt Rxt27ZrOze6iYYFbAX8xPbKXw36hJ8.vIElAX7eVxfAW+hecwE5KS5HujJJJ nb0yHluUIUHk.IWI9ARshhjJRoBIVfnjzUnRRwZz9YMuWf0h8LDUrg0vIOm1 5.q3cFYkuSK2fTkrza27gda89FiOJzX7wybv18mdFs8+FwozLsOwbJhLOmp+ ZkjZ7NtmVJz2yE7KseujvkLESvQDkoIyoKYbNPIFmHCSZ7hf6zu9iOfraQzC SIURs8ZCMOG7.IooUEU4DE8gIHFGIJynk6fkbgXsoOEhrpbgczY7L5BFmon4 a9B+Kb86sit1Zj0CQ8LWBiORBfekEykTDSB1DxJSnmXc+gk60Ul8B.n0C5in S2d6vOeChzlEfVi0y1V22bFmlJp3F1M1MmovHqOUh1cAMKoedSQ80apANZKj qHZ6pMjLtzAAlO7puf9pCtfyqTJA2YQ4YdM6sdMQ44vx5iRxs4lv8yMNXLGH xyM27.B6rIFXW98OEwc782qs6eTUYN.qPyNXzX+WmUhLeDF1wE9I65.zAt4b FStkLCnt.5ZjpbHtrXsTqwhimNcpONF8Ix50kh6PwH.gUJpD8G.kfu8ut+yS .wtThVzlv2fVwVtRqhBhaVIOBOCwTVkZiz3SmwBQI01ZL5SMCTs7cNqfoj56 B7ubNLH0RpfVQJSBBEeVKTxaMj5HA0M5lazhrZ8aH.CnopUtehtpV.cG.XRC QwJn5da0mytFBvPRqLx3sFFPN1LasBhnMteTRVesUrVa6n0PBNrT38knuSxq LwIpxAiBj8yXxTXsE3SlZSSbfGCYcI7m4Q6y5zr5SadSfzU.O40DeTB9MVCp c7saoz0.1pmbQkzXUP2qCBsnTT.i7U6MpRhaQUBvlOhiMajvA39EV4blfld+ rM.rDkS4KUq5eRpVs0Y1bTi7bHOM7rAfBNfBJr8s+QUBrkwXUQC6abyNPHwC .gTPkRxR5yXDi6fqbR8NBSkJ3YuDmzK9HZ.Bwdn8HttuvV7F1V+RXfK6KvG2 LNCq8XiBdyobB.ZNszgTOpYEeqbgWTmyHCx9XQtfn5key1TyfZbnsgFLnl0u s8pqNVcigCd6L7qlUC6Po7+BNk0Gnfk8mgcvmL435RhqOKnn3ylKYMm3MLdj dCrGYCAGDex7HE7qEKVXN8KH2PGkKwIspBE6k3fq4PjEgRrbYNs+QG8r1UcA 2MWOrKFiq1ag1wm55r+MmJy1qcrtfnSQY1AmwT.pKNxgivrsdajKN0v92gH4 XG0NaLvAR7LL3nqddD24byCttwwV7TvI43of5QOeUWAv0E8D+1zxdRc9XPKd gmOZ4CW5DqD21YI5zvJyNeGlYqyaxUOFr8nXllbRHmGqGa9xTQtnrN0EaRUI S8iBSzeKJxOIDOA09ffFd57ityhSqIyYWEcJnQ++OQiZILW00sUCFbRDvRFh yMjdeFI8gdm2iMcG6u3Vy08kM69iL42BnldYNk1c92WvLq5m+TzKEUkoMjZy uNC5wIOiJULts34VMB+jFshkkQ4sswBV1ZAjSdMHNP4ScESg3tfI+AESlcku JnB6IQ4CExEs8ecg.+vs28FgqemnvvgkBi6.lLoiMjfJpKfJdXwTPWV8vC8F fNAJuAETcwiJYXgTPWXIyZG9clCUv6PAUSIsCHp1wY48gFU2.ktzj9.p.arm olq9wau4stt5E1oc.CrL+NryKgJ76MM02jRObyut3+rflCUJ -----------end_max5_patcher-----------
sounds a bit like [phasor~], isn´t it?
i have no max here now, but it is interesting enough
to look at it later.
Well, I’ve found phasor~ to be no good for use with index~/poke~ in my patch, as it causes glitches during playback and recording, even with trunc~. It also suffers from no option to reset phase with a signal.
A signal-reset-able phasor~ would be useful, it’s just a matter of dividing the output of %~ by the length of the ramp to create a 0-1 ramp like phasor, which would then be able to be reset to 0-phase at signal rate.
What I really need to do is create these things in whatever code is needed to compile externals. alas……I cannot…yet
thanks for the prospective help!
oops – mistake
|timlloyd wrote on Tue, 25 August 2009 10:54|
|A signal-reset-able phasor~ would be useful, it’s just a matter of dividing the output of %~ by the length of the ramp to create a 0-1 ramp like phasor, which would then be able to be reset to 0-phase at signal rate.|
don’t know about a "max-only-solution", but i believe there are a few externals floating around that do what you want.
i have also done one some time ago, when i needed similar functionality. see the attachment if you are interested (osx only, though). maybe this is what you need.
Your vb.ramp~ is soo close to being exactly what I need all in one object.
As it is a one-shot ramp, I have to now figure out how to cascade a few of them so they can trigger eachother to create a looped ramp.
How difficult would it be to modify the code so it loops the ramp time length until either the ramp time is changed or the left inlet receives another zero to non-zero transition trigger?
I just noticed that vb.ramp~ seems to trigger on a non-zero to zero trnsition, when sig~ is connected to the left inlet rather than a click~.
It is almost the same as the cshot~ external I was trying this with last week (not sure who made it), and both have the problem that they don’t loop their output ramp.
It seems like the perfect object for this would be a cross between your vb.ramp~ and vb.phasor0~.
well, it loops if you send regular clicks, e.g. generated from a phasor~. possibly not what you are looking for.
but, have you checked out zigzag~?
can be triggered by a signal and has a loop mode.
in certain situations i’ve found it to be slightly inaccurate, though.
Yeah, zigzag~ is yet another slightly irksome msp object. It will loop, and the ramp can be triggered by a signal, but only in mode1, and this signal use of the left inlet means that the length of the ramp can no longer be set by a signal. Unless I missed something when reading the reference file.
Any suggestions on my original question? I’m interested to see how complex it is to achieve inside msp.
|timlloyd wrote on Tue, 25 August 2009 14:44|
|Yeah, zigzag~ is yet another slightly irksome msp object. It will loop, and the ramp can be triggered by a signal, but only in mode1, and this signal use of the left inlet means that the length of the ramp can no longer be set by a signal. Unless I missed something when reading the reference file.|
you could set the ramp with a message to [zigzag~] to something like [0 0 1 1000] before hand and control the speed of increase of the ramp by a signal to the right inlet. culprit here is that the speed inlet is only sampled once per signal vector.
might still not be what you’re looking for.
I don’t think that would work unfortunately. I need the looped ramp to control index~ and poke~ so slowing down would affect playback/recording.
I think the only solutions are either to figure out how to cascade a couple of your vb.ramp~ or the cshot~ objects, or how to reset accumulate when %~ reaches 0 in the other method.
still wrong computer with no maxmsp.
do you ned dynamic lenght?
have you tried doing it by using a counter~-generated buffer~?
buffer/play can be started by signal, do not need trunc (we
just create the "int" samples on load), can be shifted, reversed,
stopped in the middle and restarted sampleexact at any time …
p.s. i can only participate when i get a max4 code, or a max5 .pat file.
a little screenshot will also do.
Yes, the length of the ramp needs to be variable/dynamic.
I can’t think how else it is possible without sticking to the basic idea of the patch I posted earlier:
I actually emailed Andy Schmeder fomr CNMAT a week or so ago about this, because he wrote the accumulate~ object. He said he would have a think about it, but I’ve not heard back yet.
This might be what you’re looking for:
I made an absraction [wac.counter~] that uses a signal input to count samples (suitable for feeding [index~]).
The count maximum is also set by a signal. The output loops between 0 and the maximum.
There is no ‘handling’ for changing the maximum whilst the counter is looping, i.e. if the maximum is changed to some value lower than the current count it will no longer loop. I could never decide "how" i wanted to handle this so havn’t implemented it yet…
Also, resetting the count to zero is controlled by a bang, not a signal….
Hope this helps.
----------begin_max5_patcher---------- 979.3ocyY17aSCCE.+bQh+GrxE.osgeNeVtgDWgCf3DBgRS85LzXGk3xFfn+ siyyIcksrlDlSKWRVbbcdueuOs2ud5Sl4sPcCuxi7JxmHyl8KyHyvwpGYV6. y7xSuIacZENQOI+Z0hu5cVy6z7az33ZxBBc2vWpjZYZNGe0qKEoq28J4lbgb MWiKGzNpXINUyReNKZ+4p1namLa+UuR7Sb0A1Ez1wsyU+iBtUm7VjJW4cFwS HMB4mamVQpN6Jgb0WJ4YZ6LgnDyxPRn0W8CpuxL+M4y3O42O8I02M2NavbJS kmyMe16ApOVwIEJ4JxyuVnuhX9Qh7M4ufnUjKWKJH5q3DihTrQSLhsh.mSIk F8fStTURdVI+67RyRHjK42PJVm9iEoYe6Y69NqERdlZiD+XANwdDtatEk7Ji RkpEJ4dzKB4ULhPZykaw8eaDo8YD6v53CwVKBTeCBQ6SDaZrOuSUlmtVfH1f e54vd3eonpF4jhMkEpJSrSmXm4DrG34NBBH4XrHK.24l+H.XUlpfusa8g0k9 v5yMBlihUh+n7i5PaYywUhMODUWe5taOB88gR7UGKuk.DJAFc5O+t3jO7.Fd nKC+7Cj9qRrRZ9zGLyWKqrI.Cwq0gaSQn0as45bSUBnO2I+.z7yrIOlj7RAL DWA3hG4OokMJbC1n8gMFXUJV3TgMFXy+f4jBhlRp8AsxMbCl2a1KaDzDxMHJ 7Xws2ntV5FtkzK2r5Cv7mLtwNZ9au2nhZ2.tXGV9mEZK7CtCAK1n0J4Hzmf9 pp0c26Gt3UiuiMgBi5.8JmWUktheeS63qt2UWPPucAwnMEUhFR7.L58D0CQo g21GfO6hPijjLM.k5FfB8mXtAngmBfB62X0zBzycjKJ06HgFazqCQC+mKSyF wdRR7F+lKfl3S6tJrNU0WOhakJ9eQrs9gGm8D8xsNwSLxYNhCYmPsDx1.m0e jMM7wHNaIAA.0MmXV3QkSL6FcZ10SrKJ5dHN4DBEbJ7jZZ2x2eBIz0oYWfm6 DubqSN9A3jPpDrYmD1CRJ6pfGy1cOvZbYqewc3WkZSYVqvzdvxD3V4YIuRKj X6B6MKiqBYutCtRrbIW9WYWyEKKTBotQPNjUcvxVcaL6+Y6V1PM33Kb28y1s vAmFxgmW1.PG6jHcChb2SE5W3f3Xr9THFx3SS18jabGCFjE2LI1wOTgMDYaz NiLH.6.kZ2prku3StQpoShTWWEdBk5A49FeRhrBGpGJLJufX69PhaJEM2hUm EWMDgN5+WdF8OxSFX6Ybt8+CU8SNQnGbZpGGOqGvb6O.Cif4wA -----------end_max5_patcher-----------
----------begin_max5_patcher---------- 1232.3oc0Z11aaaCD.9yt.8+.g6WbVcb3q5kf0AztBrOs9GnnXP1hNQa1TBV xMYsn92d4KRttY1Nj1hRd4CVQzRj28n6Nd2I+0W9hACml+HubH3VvGACF7U4 HCzioFYPy.CFtL4wYKRJ0W3PA+g7o+8vw0eWE+wJ83udC.scz44hJQxRt9ad 6prjEa+prT8fx43ZBd6nh0KyDK3U50.u6zTl8E8zDOAtyEmutp4pQMCWjTM6 9Lwc+0J9rJiRgBgxaCfiXpCD7D1X4XSffO0bSlIp5eK3l6XXY1cBo3B9j9B9 1Keg5n7vXqIzz0UU4h8pvn8qvnSPynAJUBAC0JHr4yinYSSD2cN507E4R4yw mw33mQk28YLBenGx3igBBUihH0cChoVfBopjTMb74yjC4MTvS9mjkEabkVgd 2in1tgEoNvH5SBs.Vd.RW6bDiXeiGLw3OEhrNfQlvKvIYZoqVOHlC9Zml0Sc 3l.CdfVX8b9wSmkubIWB4+Ch9870R8Ajl+f3l0EfpbP08bPYAeV17LdJPNKY KWuD7v8bAHSTrtBjUBD4hq+BeU914aQlfOSMUpIk3nCKxkvavIHX.kFuevCO pco1SMHVSbI3YwgPjz3jhTzu8Y6eZXmqwufcCNT1gDZDNHTZLhQSHx+nTY7r vIALTHEo1NvOf4cu8C+AXzJdIuRYworjtZ+lRXG8di6HSIFbK6PAvsrSZa0v NBzOr68YJwHKWbK3ZDXjxw8pw.HXTYUdg7+jistnknYT2Py.1NQB2wu7LQ3g 1U321.ft5SF36MMCw+H1TGki8g3yudB7g4a9Xxo3hfO+xFommq.h1M.J5R.P u14T1IcCcP5hiT62++M6Gj2KpgPzlNXTTGZAYlx8pvNUkO7YezSXlsWXMe9C 8pYqV0RaToaAkxBOWvAlcNOY0SK260fe+Z2IUrkIcVS0D6S8NTOL1m5aRISq 07UMolAFotiq7.FHsFFZZRElYMF1Z8dL6flxepsGdkGf.s0ffwRmRaWDnsF. 4ymeSt.LBdC5LrDNXWL1.BnNFRz6obfHlPgHMPIAcRg5GhPKxSR0NttAo.e2 MCrgNXrw1KxBH4q9ElVVTVkTwcM6iv1fQTKXjosgLpELR0Prw6zi05y8TexN kLRh5n26.gZ5SVXu59UxEoa.uBlxW3Zlav1v7B97MTjB0fJXGWvVGCxEkm8Y 9IRBjuCFwL4BY7vBi6UKFmKBBg6nhfhBqKBB1qEA4Jd7dMh09QjPp0go8Ged yabFPztBPT8AFre8ubGPdOYn5W7E0TKx4rik4Vzcu8o+1Bzqq5KdB0JyWuZV y717SC.ryhmxKqxDIpdGuyUE8yWz8YoobwOskyxrzhbYlG0BxwdVZurYin8T EnqjMjMBm50L2CB2SW1CHbw8hvgtjImZUwOmr0ObK1FrIq2Ef5bQKvFQqedf FYinoRanGvlZyXKEtKU2TU9n8.4rZSKTfqfCaZMAFo68urRbV8IsCQ8jT2ND 0pMaQN6DafHhRTGHR91bV6H0VE4A2Ot2p22oEBGseddSslbcuvYmrEbAKarK Ym39IiYTnsUZ3jqZcLEBxTIUb31yZGo1pHLn9gn1IarK2h25GQyp3x5jy5gb BsW35ACN6hu.OagSMf7v2AvfMj6K -----------end_max5_patcher-----------
Very nice, this seems to work how I need it to. I’ve not got much free time over the next 2 days, but I’ve thrown together a little patch with your wac.counter~ that seems to be working just right!
I’ll have to have a look at how the abstraction works tomorrow evening, and optimize my mock-up patch. I’m not 100% sure that I’ve done it in the most accurate way possible.
My only concern is whether or not the send~/receive~ pair in wac.counter~ is affecting the accuracy of the signal in any way. I’ll have a look at it later.
Thanks very much!
----------begin_max5_patcher---------- 1124.3ocyYssjahCD8Y6uBEdIuLwAID3gs1rUsOteColZKLHaqs.IWfXmIIU 729paL9Rv1xFP0NOfrD259zmt6iX9w7YAq3uQZB.+F3qfYy9w7YyzKoVXlc9 rfpr2xKyZzWVPNuphvDAOYNmf7lPuNilS9.3O5VeMmIZnemnNGDsHztLqshx JIB8yBdXQdqna0tKcWlHeKks4uqI4BiEtLT9f.nnX0.NQOQtD3E6sPKzlBe0 +7oX7wVBKqRaIA+YMMqLPcheNet5vSCzs+8S+aRceDT6+vTy.75..xO..iK. Ms0D.cMPrk.9zd.sAjyqU1MPvk+rkIH0YpYxy+0BRY121Cf.3KK.f+BTvYeT .1l8uDffVQT2REooA7JUrEPEfZ5lsB.i+Z2qtjxH5Gp58GMk.dD5X.GEsTy6 d9B.dne.bHnIqZWIAnARfxMjqrcuDHkv0GajnrzK.8hVnoDsRzokPKlAwpgH b+fE9Y+.Vb1m4qWq3TMDgDqXajjpLVAnQjUK4VRjbhqYEaPkXStZ30RYwIiK nzjy2Q1Gzmaft6ZOF+Hx3AvXcpPxEbjnzGwbYjWk27uDB+796I9zuiAuoigL 8VhPKhOK.YdLhusiXtgfF5FlLfzqiubbifW.RD.JX0vYsnahJX8wjnaCJTUx GHXUFaS+HShWPFY2G3jRWfOebKggRWh8BnbniqWflH8PxupN4tfFrWfFciyv EodAXRzClRmONvf7TIlQn.yUvDaiDqhd7sgjKWYA5GlBcycVaA9f7DClfiFD MAMxchV0JDbVvn3mVoDwuKF5gi8n3QLB+kuL0MONQCEFMr.bjWn84akXOY+j x66TfEOBkGQ9o7HoXT.EzM4JHiNLWKPdMIXnwtPYa0JR8CoNeWMoQtcsLAky NV0oZu0R+LU6zg1Cu6KU7Bxky65VURNz6kYwU1MCDdxtYftmJJA30k7LQuHL zOjuOL4pbsx+sR4hhGTJIzOMneMKeg8aMcWbxn6tMscy7FXAhSGF5Lxe1Hx2 KxxGoM8aJHeXifpi84CIiXXLKOuspsLSP16EQ4VcnCKHNxaVQv2rojLNhs5R kMYxvtiWem78pydrESGNohJr98nHl1wBX5aU+AWO6+nh17TqeJR0vaqy6d8c e9HvASrfzHnLcSxiunzStnszhBB63D4JZwNtLJZMBvK8F2b1lhcwlTFN7J1T NujWaS7Nt29Sfi4hmY4vmS0edE3R8vRi3.0rA5SpZtt4S2ANCk6hUYlIFwDI GlMzHPxIf6ErVneYEINffd1jbIll7+ubGMYbzycFpkibAMi8KZhcwlPd0lbx jvd0jfPWgIGIcV9FLAuLL4ICG7JLOakOnr+qp.HZ46yFZ7G5Z1DxcvNJzziQ pIRMDiee1PCCNXr3oNHjZbGbZ2jA5TnkN5Udjt6Bo3Vchdbf1GIqmIWYB3IH ThNKEcXlOjXg7awZjKfMxuM0PtHaA4WkTHWZ9elgO4o4tvmfCgOIm7y4+GTz Ky6C -----------end_max5_patcher-----------
Investigating the ‘accuracy’ issue you mentioned, I found [wac.counter~] was looping 1 sample less than the specified maximum.
I have ammended the ‘copy compressed’ code in my above post to put an extra [+~ 1] object in there to fix it.
The send~/receive~ pair is to introduce a vectors delay; this is necessary for allowing the output of the [+=~] to be fed back into itself.
There is a dspstate object (that reports the current vector size) feeding a [- ] to compensate for the vector delay in the calculations.