See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj https://github.com/rjdj/rjlib/tree/master/rj
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at wrote:
From: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Subject: Re: [PD] Update cyclone maintenance Date: June 5, 2015 at 4:34:55 PM EDT To: Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>
I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input.
cheers
Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone.
An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone.
Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible.
cheers
2015-06-05 17:50 GMT-03:00 Dan Wilcox danomatika@gmail.com:
See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at wrote:
*From: *Alexandre Torres Porres porres@gmail.com *Subject: **Re: [PD] Update cyclone maintenance* *Date: *June 5, 2015 at 4:34:55 PM EDT *To: *Fred Jan Kraan fjkraan@xs4all.nl *Cc: *"pd-list@lists.iem.at" pd-list@lists.iem.at
I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input.
cheers
[m_scale] is an abstraction ...
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres porres@gmail.com wrote:
Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone.
An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone.
Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible.
cheers
2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj https://github.com/rjdj/rjlib/tree/master/rj
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Subject: Re: [PD] Update cyclone maintenance Date: June 5, 2015 at 4:34:55 PM EDT To: Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>
I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input.
cheers
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox danomatika@gmail.com:
[m_scale] is an abstraction ...
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres porres@gmail.com wrote:
Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone.
An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone.
Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible.
cheers
2015-06-05 17:50 GMT-03:00 Dan Wilcox danomatika@gmail.com:
See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at wrote:
*From: *Alexandre Torres Porres porres@gmail.com *Subject: **Re: [PD] Update cyclone maintenance* *Date: *June 5, 2015 at 4:34:55 PM EDT *To: *Fred Jan Kraan fjkraan@xs4all.nl *Cc: *"pd-list@lists.iem.at" pd-list@lists.iem.at
I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input.
cheers
another bug, now in [slide~], it needs a ramp up value that is small, so the ramp down works. On the other hand, ramp down value can be zero and ramp up will still work. Check attached file.
I was able to implement slide~ with vanilla objects only and with [fexpr~], it works fine without this bug, but I found that the formula needs to have at least a value of "1" to work, so [max~ 1] does the job. but when it receives a "0", the audio will actually become constant, so it's not related to the bug in the slide~ object, where the ramp just doesn't happen.
cheers
2015-06-06 17:26 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox danomatika@gmail.com:
[m_scale] is an abstraction ...
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres porres@gmail.com wrote:
Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone.
An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone.
Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible.
cheers
2015-06-05 17:50 GMT-03:00 Dan Wilcox danomatika@gmail.com:
See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at wrote:
*From: *Alexandre Torres Porres porres@gmail.com *Subject: **Re: [PD] Update cyclone maintenance* *Date: *June 5, 2015 at 4:34:55 PM EDT *To: *Fred Jan Kraan fjkraan@xs4all.nl *Cc: *"pd-list@lists.iem.at" pd-list@lists.iem.at
I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input.
cheers
Hi Alexandre,
another bug, now in [slide~], it needs a ramp up value that is small, so the ramp down works. On the other hand, ramp down value can be zero and ramp up will still work. Check attached file.
Fixed this one too. I will try to fix cycle~ too before updating all binary packages.
I was able to implement slide~ with vanilla objects only and with [fexpr~], it works fine without this bug, but I found that the formula needs to have at least a value of "1" to work, so [max~ 1] does the job. but when it receives a "0", the audio will actually become constant, so it's not related to the bug in the slide~ object, where the ramp just doesn't happen.
The slide~ object will effectively use 1 for up and down values smaller than 1. Which is sensible as it represents the number of samples of the slide.
cheers
Thank you & greetings,
Fred Jan
2015-06-06 17:26 GMT-03:00 Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com>:
I have another bug to report, now in [rampsmooth~]. According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't. In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~]. I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help. cheers 2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: [m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From: *Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> *Subject: **Re: [PD] Update cyclone maintenance* *Date: *June 5, 2015 at 4:34:55 PM EDT *To: *Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> *Cc: *"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers
Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC
cheers, jan
On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
[m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> *Subject:**Re: [PD] Update cyclone maintenance* *Date:*June 5, 2015 at 4:34:55 PM EDT *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Jan,
Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed.
Greetings,
Fred Jan
On 2015-06-07 11:33 AM, Jan Baumgart wrote:
Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC
cheers, jan
On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
[m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> *Subject:**Re: [PD] Update cyclone maintenance* *Date:*June 5, 2015 at 4:34:55 PM EDT *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yeah, we have slide~ for logarithmic ramps and rampsmooth~ in max is inteded to be only a linear ramp smoother, so I find it weird that there's this option in the code, I guess it shouldn't be there if the idea is to make them compatible.
Anyway, I was trying to make it in a patch and I did it :) - find it attached if you care.
cheers
2015-06-07 7:28 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Jan,
Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed.
Greetings,
Fred Jan
On 2015-06-07 11:33 AM, Jan Baumgart wrote:
Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC
cheers, jan
On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
[m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> *Subject:**Re: [PD] Update cyclone maintenance* *Date:*June 5, 2015 at 4:34:55 PM EDT *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
About the [rampsmooth~], I see the new object is corrected, great! One thing though, I just realized how it has no audio signal inlets for the arguments!!! It was supposed to have them, just like [slide~] does.
cheers
2015-06-07 7:28 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Jan,
Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed.
Greetings,
Fred Jan
On 2015-06-07 11:33 AM, Jan Baumgart wrote:
Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC
cheers, jan
On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
[m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> *Subject:**Re: [PD] Update cyclone maintenance* *Date:*June 5, 2015 at 4:34:55 PM EDT *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Alexandre,
About the [rampsmooth~], I see the new object is corrected, great! One thing though, I just realized how it has no audio signal inlets for the arguments!!! It was supposed to have them, just like [slide~] does.
It would be logical to expect this, but the Max5 and Max7 documentation does not mention the inlets. They are visible, but not used in the example. A quick check with Max5 revealed they are control, not signal inlets.
cheers
Greetings,
Fred Jan
2015-06-07 7:28 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Jan, Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed. Greetings, Fred Jan On 2015-06-07 11:33 AM, Jan Baumgart wrote: > Actually, the linear version is already in cyclone's code. > You can choose at compile time by not setting > #define RAMPSMOOTH_GEOMETRIC > > cheers, > jan > > On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote: >> I have another bug to report, now in [rampsmooth~]. >> >> According to its help file, it should generate a linear ramp, but it >> doesn't. Instead, it generates a logarithmic curve just like [slide~]. I >> have attached a picture that shows how both are operating in the same >> way, where they shouldn't. >> >> In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, >> unlike [slide~]. >> >> I was actually able to implement [slide~] only with [fexpr~], making it >> 100% compatible to vanilla. If there's a filter formula tht generates >> perfectly linear ramps I can implement it I guess, but it should be >> fairly easy to change it in the object. I'll see what I can do to help. >> >> cheers >> >> 2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com>>>: >> >> [m_scale] is an abstraction ... >> >> -------- >> Dan Wilcox >> @danomatika <https://twitter.com/danomatika> >> danomatika.com <http://danomatika.com> <http://danomatika.com> >> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com> >> >>> On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres >>> <porres@gmail.com <mailto:porres@gmail.com> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> wrote: >>> >>> Yeah, I already built it with expr, so I don't really need to >>> download etxernals for that. I was just wondering if extended >>> already had such a thing, and it doesn't, so I think it's a nice >>> addon to cyclone. >>> >>> An addon to cyclone would implicate and addon to extended, but >>> then, it's not clear it'll ever be maintained again. Last time >>> anyone talked about it in this list was 6 months ago... one way or >>> another, seems like a nice addon to cyclone. >>> >>> Maybe it could be just an abstraction and it doesn't have to be a >>> compiled object, I see the point. But I'd like to try and code it >>> as an external into the cyclone library if possible. >>> >>> cheers >>> >>> 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >>> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com>>>: >>> >>> See [m_scale] in rjlib: >>> https://github.com/rjdj/rjlib/tree/master/rj >>> >>> -------- >>> Dan Wilcox >>> @danomatika <https://twitter.com/danomatika> >>> danomatika.com <http://danomatika.com> <http://danomatika.com/> >>> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com/> >>> >>>> On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> >>>> <mailto:pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at>> wrote: >>>> >>>> *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com> >>>> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> >>>> *Subject:**Re: [PD] Update cyclone maintenance* >>>> *Date:*June 5, 2015 at 4:34:55 PM EDT >>>> *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> >>>> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>> >>>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>" >>>> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>> >>>> >>>> >>>> I'm voting for a new [scale] and [scale~] object in cyclone, >>>> the second is missing completely in extended, the first is >>>> around, but in different versions, like [maxlib/scale], which >>>> has a log option, and is actually buggy, and the >>>> [expr_scale], which is just an expr abstraction. Seems like >>>> very simple externals to make and I could go ahead and code >>>> them. I think they'd be really useful. For example, [scale~] >>>> would be essential to adjust the amplitude range from LFOs to >>>> control your patches. the [scale] would be good for adjusting >>>> MIDI input. >>>> >>>> cheers >>> >>> >> >> >> >> >> _______________________________________________ >> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >
A quick check with Max5 revealed they are control, not signal inlets.
that's still true in Max7, and slide~ also has control inlets in both Max5 and 7, so perhaps you should set it to control inlets to make them perfect clones. Although I like the idea of signal inlets for both of them :)
2015-06-18 4:25 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Alexandre,
About the [rampsmooth~], I see the new object is corrected, great! One thing though, I just realized how it has no audio signal inlets for the arguments!!! It was supposed to have them, just like [slide~] does.
It would be logical to expect this, but the Max5 and Max7 documentation does not mention the inlets. They are visible, but not used in the example. A quick check with Max5 revealed they are control, not signal inlets.
cheers
Greetings,
Fred Jan
2015-06-07 7:28 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Jan, Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the codefor
now, but could make the change possible at run-time, as it wasintended.
But as we already have [slide~] for this, it is not very needed. Greetings, Fred Jan On 2015-06-07 11:33 AM, Jan Baumgart wrote: > Actually, the linear version is already in cyclone's code. > You can choose at compile time by not setting > #define RAMPSMOOTH_GEOMETRIC > > cheers, > jan > > On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote: >> I have another bug to report, now in [rampsmooth~]. >> >> According to its help file, it should generate a linear ramp, butit
>> doesn't. Instead, it generates a logarithmic curve just like [slide~]. I >> have attached a picture that shows how both are operating in thesame
>> way, where they shouldn't. >> >> In MAX, [rampsmooth~] does in fact generate a perfectly linearramp,
>> unlike [slide~]. >> >> I was actually able to implement [slide~] only with [fexpr~], making it >> 100% compatible to vanilla. If there's a filter formula thtgenerates
>> perfectly linear ramps I can implement it I guess, but it shouldbe
>> fairly easy to change it in the object. I'll see what I can do to help. >> >> cheers >> >> 2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com>>>: >> >> [m_scale] is an abstraction ... >> >> -------- >> Dan Wilcox >> @danomatika <https://twitter.com/danomatika> >> danomatika.com <http://danomatika.com> <http://danomatika.com >> robotcowboy.com <http://robotcowboy.com> <>> >>> On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres >>> <porres@gmail.com <mailto:porres@gmail.com> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> wrote: >>> >>> Yeah, I already built it with expr, so I don't really need to >>> download etxernals for that. I was just wondering if extended >>> already had such a thing, and it doesn't, so I think it's anice
>>> addon to cyclone. >>> >>> An addon to cyclone would implicate and addon to extended,but
>>> then, it's not clear it'll ever be maintained again. Lasttime
>>> anyone talked about it in this list was 6 months ago... one way or >>> another, seems like a nice addon to cyclone. >>> >>> Maybe it could be just an abstraction and it doesn't have to be a >>> compiled object, I see the point. But I'd like to try and code it >>> as an external into the cyclone library if possible. >>> >>> cheers >>> >>> 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >>> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com:
>>> >>> See [m_scale] in rjlib: >>> https://github.com/rjdj/rjlib/tree/master/rj >>> >>> -------- >>> Dan Wilcox >>> @danomatika <https://twitter.com/danomatika> >>> danomatika.com <http://danomatika.com> <http://danomatika.com/> >>> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com/> >>> >>>> On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> >>>> <mailto:pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at>> wrote: >>>> >>>> *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com> >>>> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> >>>> *Subject:**Re: [PD] Update cyclone maintenance* >>>> *Date:*June 5, 2015 at 4:34:55 PM EDT >>>> *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> >>>> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>> >>>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>" >>>> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>> >>>> >>>> >>>> I'm voting for a new [scale] and [scale~] object in cyclone, >>>> the second is missing completely in extended, the firstis
>>>> around, but in different versions, like [maxlib/scale], which >>>> has a log option, and is actually buggy, and the >>>> [expr_scale], which is just an expr abstraction. Seemslike
>>>> very simple externals to make and I could go ahead andcode
>>>> them. I think they'd be really useful. For example, [scale~] >>>> would be essential to adjust the amplitude range from LFOs to >>>> control your patches. the [scale] would be good for adjusting >>>> MIDI input. >>>> >>>> cheers >>> >>> >> >> >> >> >> _______________________________________________ >> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >
About maintaining cyclone, I think a reorg would be great, and further maintenance as well. If you want to do whatever you want with it, then just make a fork and work on it as a new name. If you want to stick to cyclone's central goal of Max/MSP compatibility, then keep working on it as cyclone. But please do not work on cyclone and break the Max/MSP compatibility.
.hc
Alexandre Torres Porres:
About the [rampsmooth~], I see the new object is corrected, great! One thing though, I just realized how it has no audio signal inlets for the arguments!!! It was supposed to have them, just like [slide~] does.
cheers
2015-06-07 7:28 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Jan,
Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed.
Greetings,
Fred Jan
On 2015-06-07 11:33 AM, Jan Baumgart wrote:
Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC
cheers, jan
On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like [slide~]. I have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making it 100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
[m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one way or another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> *Subject:**Re: [PD] Update cyclone maintenance* *Date:*June 5, 2015 at 4:34:55 PM EDT *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> I'm voting for a new [scale] and [scale~] object in cyclone, the second is missing completely in extended, the first is around, but in different versions, like [maxlib/scale], which has a log option, and is actually buggy, and the [expr_scale], which is just an expr abstraction. Seems like very simple externals to make and I could go ahead and code them. I think they'd be really useful. For example, [scale~] would be essential to adjust the amplitude range from LFOs to control your patches. the [scale] would be good for adjusting MIDI input. cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N�n�r����)em�h�yhiם�w^��
But please do not work on cyclone and break the Max/MSP compatibility.
Howdy... Of course! Agreed! But not sure about the purpose of this remark considering what was being discussed with [rampsmooth~] and all - it was for the sake of compatibility. We're actually being very strict to make it exactly like Max here. For example, I've just mentioned [slide~] should have control inlets instead of audio inlets like it has. The fact that it also accepts audio signal doesn't break the compatibility, and might be nicer, but I guess it needs to be that way for it to be a proper clone.
cheers
2015-06-19 11:43 GMT-03:00 Hans-Christoph Steiner hans@at.or.at:
About maintaining cyclone, I think a reorg would be great, and further maintenance as well. If you want to do whatever you want with it, then just make a fork and work on it as a new name. If you want to stick to cyclone's central goal of Max/MSP compatibility, then keep working on it as cyclone. But please do not work on cyclone and break the Max/MSP compatibility.
.hc
Alexandre Torres Porres:
About the [rampsmooth~], I see the new object is corrected, great! One thing though, I just realized how it has no audio signal inlets for the arguments!!! It was supposed to have them, just like [slide~] does.
cheers
2015-06-07 7:28 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Jan,
Thanks for pointing this out. I had seen the logic juggling with RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the conclusion the default behaviour was incorrect. I changed the code for now, but could make the change possible at run-time, as it was intended. But as we already have [slide~] for this, it is not very needed.
Greetings,
Fred Jan
On 2015-06-07 11:33 AM, Jan Baumgart wrote:
Actually, the linear version is already in cyclone's code. You can choose at compile time by not setting #define RAMPSMOOTH_GEOMETRIC
cheers, jan
On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote:
I have another bug to report, now in [rampsmooth~].
According to its help file, it should generate a linear ramp, but it doesn't. Instead, it generates a logarithmic curve just like
[slide~]. I
have attached a picture that shows how both are operating in the same way, where they shouldn't.
In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, unlike [slide~].
I was actually able to implement [slide~] only with [fexpr~], making
it
100% compatible to vanilla. If there's a filter formula tht generates perfectly linear ramps I can implement it I guess, but it should be fairly easy to change it in the object. I'll see what I can do to
help.
cheers
2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
[m_scale] is an abstraction ... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com>On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: Yeah, I already built it with expr, so I don't really need to download etxernals for that. I was just wondering if extended already had such a thing, and it doesn't, so I think it's a nice addon to cyclone. An addon to cyclone would implicate and addon to extended, but then, it's not clear it'll ever be maintained again. Last time anyone talked about it in this list was 6 months ago... one wayor
another, seems like a nice addon to cyclone. Maybe it could be just an abstraction and it doesn't have to be a compiled object, I see the point. But I'd like to try and code it as an external into the cyclone library if possible. cheers 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>>: See [m_scale] in rjlib: https://github.com/rjdj/rjlib/tree/master/rj -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>> On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at > mailto:pd-list-request@lists.iem.at wrote: > > *From:*Alexandre Torres Porres <porres@gmail.com > mailto:porres@gmail.com> > *Subject:**Re: [PD] Update cyclone maintenance* > *Date:*June 5, 2015 at 4:34:55 PM EDT > *To:*Fred Jan Kraan <fjkraan@xs4all.nl > mailto:fjkraan@xs4all.nl> > *Cc:*"pd-list@lists.iem.at mailto:pd-list@lists.iem.at" > <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> > > > I'm voting for a new [scale] and [scale~] object in cyclone, > the second is missing completely in extended, the first is > around, but in different versions, like [maxlib/scale],
which
> has a log option, and is actually buggy, and the > [expr_scale], which is just an expr abstraction. Seems like > very simple externals to make and I could go ahead and code > them. I think they'd be really useful. For example, [scale~] > would be essential to adjust the amplitude range from LFOs
to
> control your patches. the [scale] would be good for
adjusting
> MIDI input. > > cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N �n�r����)em�h�yhiם�w^��
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-06-19 06:37 PM, Alexandre Torres Porres wrote:
But please do not work on cyclone and break the Max/MSP compatibility.
Howdy... Of course! Agreed! But not sure about the purpose of this remark considering what was being discussed with [rampsmooth~] and all -
I asked Hans off-list about reorganizing the cyclone source tree in the svn repositry. I thought it could use some maintenance, but wasn't sure it was a good idea.
it was for the sake of compatibility. We're actually being very strict to make it exactly like Max here. For example, I've just mentioned [slide~] should have control inlets instead of audio inlets like it has. The fact that it also accepts audio signal doesn't break the compatibility, and might be nicer, but I guess it needs to be that way for it to be a proper clone.
Having signal inlets, means it works with control messages too. So it won't break compatibility, IMHO. I think it doesn't need to be perfect, as long as it close enough and usable too.
cheers
Greetings,
Fred Jan
2015-06-19 11:43 GMT-03:00 Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at>:
About maintaining cyclone, I think a reorg would be great, and further maintenance as well. If you want to do whatever you want with it, then just make a fork and work on it as a new name. If you want to stick to cyclone's central goal of Max/MSP compatibility, then keep working on it as cyclone. But please do not work on cyclone and break the Max/MSP compatibility. .hc Alexandre Torres Porres: > About the [rampsmooth~], I see the new object is corrected, great! One > thing though, I just realized how it has no audio signal inlets for the > arguments!!! It was supposed to have them, just like [slide~] does. > > cheers > > 2015-06-07 7:28 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>: > >> Hi Jan, >> >> Thanks for pointing this out. I had seen the logic juggling with >> RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the >> conclusion the default behaviour was incorrect. I changed the code for >> now, but could make the change possible at run-time, as it was intended. >> But as we already have [slide~] for this, it is not very needed. >> >> >> Greetings, >> >> Fred Jan >> >> On 2015-06-07 11:33 AM, Jan Baumgart wrote: >>> Actually, the linear version is already in cyclone's code. >>> You can choose at compile time by not setting >>> #define RAMPSMOOTH_GEOMETRIC >>> >>> cheers, >>> jan >>> >>> On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote: >>>> I have another bug to report, now in [rampsmooth~]. >>>> >>>> According to its help file, it should generate a linear ramp, but it >>>> doesn't. Instead, it generates a logarithmic curve just like [slide~]. I >>>> have attached a picture that shows how both are operating in the same >>>> way, where they shouldn't. >>>> >>>> In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, >>>> unlike [slide~]. >>>> >>>> I was actually able to implement [slide~] only with [fexpr~], making it >>>> 100% compatible to vanilla. If there's a filter formula tht generates >>>> perfectly linear ramps I can implement it I guess, but it should be >>>> fairly easy to change it in the object. I'll see what I can do to help. >>>> >>>> cheers >>>> >>>> 2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >>>> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com>>>: >>>> >>>> [m_scale] is an abstraction ... >>>> >>>> -------- >>>> Dan Wilcox >>>> @danomatika <https://twitter.com/danomatika> >>>> danomatika.com <http://danomatika.com> <http://danomatika.com> >>>> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com> >>>> >>>>> On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres >>>>> <porres@gmail.com <mailto:porres@gmail.com> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> wrote: >>>>> >>>>> Yeah, I already built it with expr, so I don't really need to >>>>> download etxernals for that. I was just wondering if extended >>>>> already had such a thing, and it doesn't, so I think it's a nice >>>>> addon to cyclone. >>>>> >>>>> An addon to cyclone would implicate and addon to extended, but >>>>> then, it's not clear it'll ever be maintained again. Last time >>>>> anyone talked about it in this list was 6 months ago... one way or >>>>> another, seems like a nice addon to cyclone. >>>>> >>>>> Maybe it could be just an abstraction and it doesn't have to be a >>>>> compiled object, I see the point. But I'd like to try and code it >>>>> as an external into the cyclone library if possible. >>>>> >>>>> cheers >>>>> >>>>> 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >>>>> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com>>>: >>>>> >>>>> See [m_scale] in rjlib: >>>>> https://github.com/rjdj/rjlib/tree/master/rj >>>>> >>>>> -------- >>>>> Dan Wilcox >>>>> @danomatika <https://twitter.com/danomatika> >>>>> danomatika.com <http://danomatika.com> <http://danomatika.com/> >>>>> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com/> >>>>> >>>>>> On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> >>>>>> <mailto:pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at>> wrote: >>>>>> >>>>>> *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com> >>>>>> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> >>>>>> *Subject:**Re: [PD] Update cyclone maintenance* >>>>>> *Date:*June 5, 2015 at 4:34:55 PM EDT >>>>>> *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> >>>>>> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>> >>>>>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>" >>>>>> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>> >>>>>> >>>>>> >>>>>> I'm voting for a new [scale] and [scale~] object in cyclone, >>>>>> the second is missing completely in extended, the first is >>>>>> around, but in different versions, like [maxlib/scale], which >>>>>> has a log option, and is actually buggy, and the >>>>>> [expr_scale], which is just an expr abstraction. Seems like >>>>>> very simple externals to make and I could go ahead and code >>>>>> them. I think they'd be really useful. For example, [scale~] >>>>>> would be essential to adjust the amplitude range from LFOs to >>>>>> control your patches. the [scale] would be good for adjusting >>>>>> MIDI input. >>>>>> >>>>>> cheers >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >> >> >> >> N �n�r����)em�h�yhiם�w^�� _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
Does anybody know if there is an existing arduino software for this?
Does anybody know if there are limitations on some or even all arduinos
using the serial (digatal 0/1) ports and USB port at the same time?
(BTW, I'm already aware of the electronic parts that are needed for the MIDI In/Out.)
Thanks in advance!
Ingo
On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote:
Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
- Does anybody know if there are limitations on some or even all arduinos
using the serial (digatal 0/1) ports and USB port at the same time?
Only the micro (or Leonardo or Mega) will work for this as the TTL serial
is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set to 31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for this and can also (I believe) be set up as a USB MIDI device.
Martin
I would definitely consider the Teensy unless there are specific reasons for the Arduino. The newest version has MIDI support built into and it is compatible with Arduino sketches.
On Sat, Jun 20, 2015 at 11:11 AM, Martin Peach chakekatzil@gmail.com wrote:
On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote:
Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
- Does anybody know if there are limitations on some or even all arduinos
using the serial (digatal 0/1) ports and USB port at the same time?
Only the micro (or Leonardo or Mega) will work for this as the TTL serial
is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set to 31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for this and can also (I believe) be set up as a USB MIDI device.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks, Martin and Paul!
The Teensy is great but seems to need some extra electronics since it is operating at 3.3V in order to get a reliable MIDI In/Out with 5V (according to a friend who is also working on something like this). The Arduinos with 5V should be easier. Of course for more complex stuff the Teensy with 3 serial ports has a lot more power.
I kind of suspected the Nano (or the older Arduinos) not to work - good to know now!
Ingo
Von: Paul Batchelor [mailto:ralphbluecoat@gmail.com] Gesendet: Samstag, 20. Juni 2015 17:39 An: Martin Peach Cc: Ingo; pd-list@lists.iem.at Betreff: Re: [PD] Arduiano (Micro or Nano) as MIDI interface?
I would definitely consider the Teensy unless there are specific reasons for the Arduino. The newest version has MIDI support built into and it is compatible with Arduino sketches.
On Sat, Jun 20, 2015 at 11:11 AM, Martin Peach chakekatzil@gmail.com wrote: On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote: Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
2) Does anybody know if there are limitations on some or even all arduinos using the serial (digatal 0/1) ports and USB port at the same time?
Only the micro (or Leonardo or Mega) will work for this as the TTL serial is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set to 31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for this and can also (I believe) be set up as a USB MIDI device.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The teensy2.0 is 5V so it should work fine. (The Teensy3.1s are 3.3V but can handle 5V so they could work if you use 50ohm resistors on the outputs instead of 220 to get 5mA, but that's not strictly correct according to the MIDI spec, which says 5V.)
Martin
On Sat, Jun 20, 2015 at 1:10 PM, Ingo ingo@miamiwave.com wrote:
Thanks, Martin and Paul!
The Teensy is great but seems to need some extra electronics since it is operating at 3.3V in order to get a reliable MIDI In/Out with 5V (according to a friend who is also working on something like this). The Arduinos with 5V should be easier. Of course for more complex stuff the Teensy with 3 serial ports has a lot more power.
I kind of suspected the Nano (or the older Arduinos) not to work - good to know now!
Ingo
Von: Paul Batchelor [mailto:ralphbluecoat@gmail.com] Gesendet: Samstag, 20. Juni 2015 17:39 An: Martin Peach Cc: Ingo; pd-list@lists.iem.at Betreff: Re: [PD] Arduiano (Micro or Nano) as MIDI interface?
I would definitely consider the Teensy unless there are specific reasons for the Arduino. The newest version has MIDI support built into and it is compatible with Arduino sketches.
On Sat, Jun 20, 2015 at 11:11 AM, Martin Peach chakekatzil@gmail.com wrote: On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote: Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
- Does anybody know if there are limitations on some or even all arduinos
using the serial (digatal 0/1) ports and USB port at the same time?
Only the micro (or Leonardo or Mega) will work for this as the TTL serial is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set to 31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for this and can also (I believe) be set up as a USB MIDI device.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Cool, I'll take a look at the teensy 2.0. I didn't know it runs on 5V. I have a teensy 3.1 here and check if the 50R does the trick.
Ingo
Von: Martin Peach [mailto:chakekatzil@gmail.com] Gesendet: Samstag, 20. Juni 2015 19:26 An: Ingo Cc: Paul Batchelor; pd-list@lists.iem.at Betreff: Re: [PD] Arduiano (Micro or Nano) as MIDI interface?
The teensy2.0 is 5V so it should work fine. (The Teensy3.1s are 3.3V but can handle 5V so they could work if you use 50ohm resistors on the outputs instead of 220 to get 5mA, but that's not strictly correct according to the MIDI spec, which says 5V.) Martin
On Sat, Jun 20, 2015 at 1:10 PM, Ingo ingo@miamiwave.com wrote: Thanks, Martin and Paul!
The Teensy is great but seems to need some extra electronics since it is operating at 3.3V in order to get a reliable MIDI In/Out with 5V (according to a friend who is also working on something like this). The Arduinos with 5V should be easier. Of course for more complex stuff the Teensy with 3 serial ports has a lot more power.
I kind of suspected the Nano (or the older Arduinos) not to work - good to know now!
Ingo
Von: Paul Batchelor [mailto:ralphbluecoat@gmail.com] Gesendet: Samstag, 20. Juni 2015 17:39 An: Martin Peach Cc: Ingo; pd-list@lists.iem.at Betreff: Re: [PD] Arduiano (Micro or Nano) as MIDI interface?
I would definitely consider the Teensy unless there are specific reasons for the Arduino. The newest version has MIDI support built into and it is compatible with Arduino sketches.
On Sat, Jun 20, 2015 at 11:11 AM, Martin Peach chakekatzil@gmail.com wrote: On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote: Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
2) Does anybody know if there are limitations on some or even all arduinos using the serial (digatal 0/1) ports and USB port at the same time?
Only the micro (or Leonardo or Mega) will work for this as the TTL serial is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set to 31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for this and can also (I believe) be set up as a USB MIDI device.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Both the Arduino Micro and the Teensy 2.0 are working great! Thanks a lot, Martin!
Now I only need to find out how I can prepend some identifier in the Arduino patch to be able to route the MIDI data separately while using the other pins with the standard firmata at the same time.
Unfortunately I do know much about C programming ...
Ingo
Von: Martin Peach [mailto:chakekatzil@gmail.com] Gesendet: Samstag, 20. Juni 2015 17:11 An: Ingo Cc: pd-list@lists.iem.at Betreff: Re: [PD] Arduiano (Micro or Nano) as MIDI interface?
On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote: Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
2) Does anybody know if there are limitations on some or even all arduinos using the serial (digatal 0/1) ports and USB port at the same time? Only the micro (or Leonardo or Mega) will work for this as the TTL serial is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set to 31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for this and can also (I believe) be set up as a USB MIDI device.
Martin
Of courese I meant to say: " Unfortunately I do NOT know much about C programming ..."
Both the Arduino Micro and the Teensy 2.0 are working great! Thanks a lot, Martin!
Now I only need to find out how I can prepend some identifier in the Arduino patch to be able to route the MIDI data separately while using the other pins with the standard firmata at the same time.
Unfortunately I do know much about C programming ...
Ingo
Von: Martin Peach [mailto:chakekatzil@gmail.com] Gesendet: Samstag, 20. Juni 2015 17:11 An: Ingo Cc: pd-list@lists.iem.at Betreff: Re: [PD] Arduiano (Micro or Nano) as MIDI interface?
On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote: Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
- Does anybody know if there are limitations on some or even all arduinos
using the serial (digatal 0/1) ports and USB port at the same time? Only the micro (or Leonardo or Mega) will work for this as the TTL serial is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set to 31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for this and can also (I believe) be set up as a USB MIDI device.
Martin
I think it would be easier to use MIDI to control/read the arduino pins than to combine it with firmata. If the arduino was on its own MIDI channel then noteon messages on that channel could set or read the digital outs and controller messages the analog pins.
Martin
On Tue, Jun 30, 2015 at 6:17 AM, Ingo ingo@miamiwave.com wrote:
Of courese I meant to say: " Unfortunately I do NOT know much about C programming ..."
Both the Arduino Micro and the Teensy 2.0 are working great! Thanks a lot, Martin!
Now I only need to find out how I can prepend some identifier in the Arduino patch to be able to route the MIDI data separately while using the other pins with the standard firmata at the same time.
Unfortunately I do know much about C programming ...
Ingo
Von: Martin Peach [mailto:chakekatzil@gmail.com] Gesendet: Samstag, 20. Juni 2015 17:11 An: Ingo Cc: pd-list@lists.iem.at Betreff: Re: [PD] Arduiano (Micro or Nano) as MIDI interface?
On Sat, Jun 20, 2015 at 6:06 AM, Ingo ingo@miamiwave.com wrote: Hi there!
I'd like to use an Arduino Micro (or Nano) as a MIDI interface connecting the MIDI ports to the digital pins "0" and "1" (TX/RX) and receiving the MIDI data via USB in Pd. It does not matter in which format it comes into Pd (i.e. it doesn't have to show up as a MIDI port - like MIDI over USB).
- Does anybody know if there is an existing arduino software for this?
No but all you need to do is if (Serial.available()) Serial1.write(Serial.read()); if (Serial1.available()) Serial.write(Serial1.read()); in your main loop, where Serial1 is the TTL serial and Serial is USB.
- Does anybody know if there are limitations on some or even all
arduinos
using the serial (digatal 0/1) ports and USB port at the same time? Only the micro (or Leonardo or Mega) will work for this as the TTL serial is separate from the USB. The TTL serial port on pins 0 and 1 shoud be set
to
31250 baud. Arduinos that use the Atmega168 or 328 use the same serial port for TTL and USB so there will be conflicts if you try to do both at the same time. And software serial is probably too slow to receive at 31250 baud although it can work to send MIDI that way. Teensy2.0 (http://www.pjrc.com/teensy/index.html) will also work for
this
and can also (I believe) be set up as a USB MIDI device.
Martin
I've been trying to find out since over 5 years about how to write udev rules that allow me setting up an order for varying MIDI interfaces that can be recognized in the correct order by Pd. Unfortunately without any success!
The only thing that works so far is using vendor and product id in /etc/modprobe.d/alsabase.conf. Like this:
options snd-usb-audio index=2,2,3,3,4,5, vid=0xnnnn, 0xnnnn, 0xnnnn, 0xnnnn, 0xnnnn, 0xnnnn pid=0xnnnn, 0xnnnn, 0xnnnn, 0xnnnn, 0xnnnn, 0xnnnn
I can assign up to two vid/pid numbers per index and it still works as long as only one of them is present. With more than two it doesn't work anymore ... :-(
I also found this somewhere:
options snd-usb-audio index=1,2,3,4 id=midi1, midi2, midi3, midi4
I have no idea what this is supposed to do or where "midi1", etc. comes from. If I write a udev rule that places "midi1" in /dev/ or /dev/snd/ it shows up but doesn't do anything.
What I need to do is assigning varying USB MIDI interfaces to the first id, the 2nd id, etc.
What can I do that a udev rule creates an "id" that is being recognized by alsa or oss?
BTW, even with the vid/pid that is generally working the indexes change if one is missing. I.e. if the first interface is not present the second will be taken as the first one and the following ids will be one less.
Any help is appreciated!
I would like to do something like this:
- write a udev rule for every interface that might be in use with a common
name like "midi1" or "midi2", etc. 2) assign the udev name that I have created to an id in modprobe.d/alsabase.conf to be seen as a midi device by Pd.
Thanks! Ingo
I see, now it makes sense :)
I think it doesn't need to be perfect
You know what? Me too, haha
take care
2015-06-20 5:43 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
On 2015-06-19 06:37 PM, Alexandre Torres Porres wrote:
But please do not work on cyclone and break the Max/MSP compatibility.
Howdy... Of course! Agreed! But not sure about the purpose of this remark considering what was being discussed with [rampsmooth~] and all -
I asked Hans off-list about reorganizing the cyclone source tree in the svn repositry. I thought it could use some maintenance, but wasn't sure it was a good idea.
it was for the sake of compatibility. We're actually being very strict to make it exactly like Max here. For example, I've just mentioned [slide~] should have control inlets instead of audio inlets like it has. The fact that it also accepts audio signal doesn't break the compatibility, and might be nicer, but I guess it needs to be that way for it to be a proper clone.
Having signal inlets, means it works with control messages too. So it won't break compatibility, IMHO. I think it doesn't need to be perfect, as long as it close enough and usable too.
cheers
Greetings,
Fred Jan
2015-06-19 11:43 GMT-03:00 Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at>:
About maintaining cyclone, I think a reorg would be great, andfurther
maintenance as well. If you want to do whatever you want with it, then just make a fork and work on it as a new name. If you want to stick to cyclone's central goal of Max/MSP compatibility, then keep working on it as cyclone. But please do not work on cyclone and break the Max/MSP compatibility. .hc Alexandre Torres Porres: > About the [rampsmooth~], I see the new object is corrected, great!One
> thing though, I just realized how it has no audio signal inlets for the > arguments!!! It was supposed to have them, just like [slide~] does. > > cheers > > 2015-06-07 7:28 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>: > >> Hi Jan, >> >> Thanks for pointing this out. I had seen the logic juggling with >> RAMPSMOOTH_GEOMETRIC and RAMPSMOOTH_LINEAR, but hadn't came to the >> conclusion the default behaviour was incorrect. I changed the code for >> now, but could make the change possible at run-time, as it was intended. >> But as we already have [slide~] for this, it is not very needed. >> >> >> Greetings, >> >> Fred Jan >> >> On 2015-06-07 11:33 AM, Jan Baumgart wrote: >>> Actually, the linear version is already in cyclone's code. >>> You can choose at compile time by not setting >>> #define RAMPSMOOTH_GEOMETRIC >>> >>> cheers, >>> jan >>> >>> On 06/06/2015 10:26 PM, Alexandre Torres Porres wrote: >>>> I have another bug to report, now in [rampsmooth~]. >>>> >>>> According to its help file, it should generate a linear ramp, but it >>>> doesn't. Instead, it generates a logarithmic curve just like [slide~]. I >>>> have attached a picture that shows how both are operating in the same >>>> way, where they shouldn't. >>>> >>>> In MAX, [rampsmooth~] does in fact generate a perfectly linear ramp, >>>> unlike [slide~]. >>>> >>>> I was actually able to implement [slide~] only with [fexpr~], making it >>>> 100% compatible to vanilla. If there's a filter formula tht generates >>>> perfectly linear ramps I can implement it I guess, but itshould be
>>>> fairly easy to change it in the object. I'll see what I can do to help. >>>> >>>> cheers >>>> >>>> 2015-06-05 18:08 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >>>> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com>>>: >>>> >>>> [m_scale] is an abstraction ... >>>> >>>> -------- >>>> Dan Wilcox >>>> @danomatika <https://twitter.com/danomatika> >>>> danomatika.com <http://danomatika.com> <>>>> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com> >>>> >>>>> On Jun 5, 2015, at 5:05 PM, Alexandre Torres Porres >>>>> <porres@gmail.com <mailto:porres@gmail.com> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> wrote: >>>>> >>>>> Yeah, I already built it with expr, so I don't really needto
>>>>> download etxernals for that. I was just wondering ifextended
>>>>> already had such a thing, and it doesn't, so I think it's a nice >>>>> addon to cyclone. >>>>> >>>>> An addon to cyclone would implicate and addon to extended,but
>>>>> then, it's not clear it'll ever be maintained again. Lasttime
>>>>> anyone talked about it in this list was 6 months ago... one way or >>>>> another, seems like a nice addon to cyclone. >>>>> >>>>> Maybe it could be just an abstraction and it doesn't have to be a >>>>> compiled object, I see the point. But I'd like to try and code it >>>>> as an external into the cyclone library if possible. >>>>> >>>>> cheers >>>>> >>>>> 2015-06-05 17:50 GMT-03:00 Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com> >>>>> <mailto:danomatika@gmail.com <mailto:danomatika@gmail.com:
>>>>> >>>>> See [m_scale] in rjlib: >>>>> https://github.com/rjdj/rjlib/tree/master/rj >>>>> >>>>> -------- >>>>> Dan Wilcox >>>>> @danomatika <https://twitter.com/danomatika> >>>>> danomatika.com <http://danomatika.com> <http://danomatika.com/> >>>>> robotcowboy.com <http://robotcowboy.com> <http://robotcowboy.com/> >>>>> >>>>>> On Jun 5, 2015, at 4:35 PM, pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at> >>>>>> <mailto:pd-list-request@lists.iem.at <mailto:pd-list-request@lists.iem.at>> wrote: >>>>>> >>>>>> *From:*Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com> >>>>>> <mailto:porres@gmail.com <mailto:porres@gmail.com>>> >>>>>> *Subject:**Re: [PD] Update cyclone maintenance* >>>>>> *Date:*June 5, 2015 at 4:34:55 PM EDT >>>>>> *To:*Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> >>>>>> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>>>>> *Cc:*"pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>" >>>>>> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> <mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>> >>>>>> >>>>>> >>>>>> I'm voting for a new [scale] and [scale~] object in cyclone, >>>>>> the second is missing completely in extended, the first is >>>>>> around, but in different versions, like [maxlib/scale], which >>>>>> has a log option, and is actually buggy, and the >>>>>> [expr_scale], which is just an expr abstraction. Seems like >>>>>> very simple externals to make and I could go ahead and code >>>>>> them. I think they'd be really useful. For example, [scale~] >>>>>> would be essential to adjust the amplitude range from LFOs to >>>>>> control your patches. the [scale] would be good for adjusting >>>>>> MIDI input. >>>>>> >>>>>> cheers >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >> >> >> >> N �n�r����)em�h�yhiם�w^�� _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Dan Wilcox -
Fred Jan Kraan -
Hans-Christoph Steiner -
Ingo -
Jan Baumgart -
Martin Peach -
Paul Batchelor